I have to use an unmanaged SNAPSHOT dependency in my java/maven heroku app.
I do this using a project-local maven repository as desribed in this article.
Heroku caches the dependencies between builds. Unfortunatly Heroku does not notice if the SNAPSHOT Version changes and keeps on using the cached dependency. This leads to compilation errors as I depend on changes in the SNAPSHOT version.
Is there a way to manually or automatically clean this dependency cache?
I found this maven plugin (it does a local build and pushes the resulting artefacts to heroku) but its not really the way I want to do it.
One could argue its a bad practice to use this snapshot dependency in the first place but I think there are other more or less valid reasons for cleaning the cash e.g. leaking storage as the unmanaged dependencies are not even removed if they are deleted from the project local repository.
I appreciate your answer
There's a branch of the java buildpack that clears maven cache. To use it, configure your app to use the cache_clear branch:
heroku config:set BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-java.git#cache_clear
===Update===
There's a plugin that clears cache on any app. Install it and run the purge-cache command.
$ heroku plugins:install https://github.com/heroku/heroku-repo.git
$ heroku repo:purge_cache -a appname
Login to heroko by console, go to the git repository directory of your app, run the following commands and try to push to the heroku git repository again
$ heroku config:set MAVEN_CUSTOM_GOALS="clean package"
$ heroku config:set MAVEN_CUSTOM_OPTS="--update-snapshots -DskipTests=true"
Now, it will download the latest SNAPSHOT from the repository before build.
Refer this heroku build pack for java for more details.
You can also configure a custom settings.xml for your maven, refer this heroku documentation.
I've written plugin with an alternate take: bundling the container + the war image into a git repository base image (for now, its either winstone and/or jetty) which is pushed to Heroku, thus maving easier to deploy (I think) :]
http://cedarhero.ingenieux.com.br/heroku-maven-plugin/
This doesn't answer the question directly, but if you're having the same issue with Clojure project (using Leiningen), there's a better way to handle this than purging cache with each build: use :update :always property for the repository you're working with. (https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L91)
:repositories [["releases" {:url "http://blueant.com/archiva/internal"
;; How often should this repository be checked for
;; snapshot updates? (:daily, :always, or :never)
:update :always}]]
Related
So I have a Maven project and I'd like to deploy it on Heroku via Github. To be more precise I want to use automatic deployments where when I push to my master branch only then is it deployed. The only thing I found for Maven is that I add a dependency and it would deploy to Heroku from my machine (which I essentially don't want).
I really don't know what else to say as I had 0 progress. For now I am just pushing my target as well and then just running the target jar file. But I'd like to just send over my source code and for Heroku to build the project.
Alright, so I found my solution.
I saw an example (I can't find it now, no luck) for Heroku that build the project with a thing called mvnw script which is a Maven wrapper when it's not installed on the system. I added it and the .mvn directory but it didn't start by itself like how it is written on Heroku (it should run it when it's detected), no problem really.
I then edited my Procfile and instead of:
web: java -jar target/my-file.jar
I am using:
web: ./mvnw clean package; java -jar target/my-file.jar
And everything works well!
You only need to integrate your GitHub repository on Heroku, and define the automated deployment of the master branch (each push will trigger a deployment).
Heroku will build the JAR and take care of the deployment, you need though to define the Java version in a system.properties and create an Uber-Jar (ie including all dependencies).
I have an existing Maven based application on Heroku that I want to replace with a JHipster generated, Gradle based one. The steps I took were:
Develop the new Gradle based application using JHipster
run jhipster heroku
git merge heroku --strategy ours
git push heroku
Most of the deployment succeeds (Node.js app detected, webpack logging), but then I get an error:
Could not find a pom.xml file! Please check that it exists and is committed to Git.
It is correct that there is no pom.xml, because now it is a Gradle application. But apparently, Heroku still expects a Maven based one. Where is this knowledge stored and how can I reset it?
Already found out. You have to run this command, to remove the Maven build pack:
heroku buildpacks:clear
Additionally, in my case I also had to set:
heroku buildpacks:set heroku/nodejs
Or Heroku didn't know whether to run as Gradle or NodeJS. The latter is needed for JHipster based applications.
I got a maven project (myApp) depending on another maven project in snapshot version.
like:
<dependency>
<groupId>org.group.dep</groupId>
<artifactId>arty</artifactId>
<version>12.1.4-SNAPSHOT</version>
</dependency>
But I got a problem with this after the "arty" got an update without changing the version (I know that would be the cleanest solution).
I build the myApp local and got still the old version of the "arty" dependency.
I verified tow option working for me (and a college):
1) Manual cleaning of the local repository: navigating to my .m2/repo/org/group/dep/arty and deleted all folders inside. After rebuilding the myApp local it was working fine - arty was downloaded form the artifactory.company.com again with the updated content.
2) Local building of the arty package so it got updated in the local repository. After rebuilding the myApp local it was working fine.
But I got similar problem on the Jenkins:
I got a Jenkins job just building org.group.myApp without building before org.group.dep.arty. It failed for the missing changes form "arty".
What can I do now to solve my problem there?
I can not rely on first building org.group.dep.arty as I can not be sure for Jenkins to run both jobs on the same host using same local repository (I don't want to change that).
Somehow the myApp-Jobs was failing after I manually cleared on that Jenkins node the org.group.dep.arty in the repository and running than the myApp-job (was somehow not downloading the package).
I finally found the mvn -u but as I tried this I was as well disappointed.
I tried different maven versions on that jenkins and got the same result.
Is there no way to force the update of the snapshot versions?
Is this "another project" is a part of the same multi-module project?
If so you can build your project with --also-make options so that maven will effectively rebuild your module and all of its dependencies
If its an entirely different project, use mvn -U to forcefully download all the snapshot dependencies of your project.
If there is a particular issue with one concrete dependency consider using mvn dependency:get. This get goal of maven-dependency-plugin downloads one specific artifact from the remote repository
Here is a link to the plugin documentation
The simplest solution to redownload -SNAPSHOT is by using the command line option: -U or as long option --update-snapshots
Furthermore your project sounds like the need for a multi module build which prevents such issues. Or you might need to define those Jobs depending on each other (There is an option to build if a SNAPSHOT has been updated in Jenkins).
I currently have a travis-ci setup that runs a build out of a github repository. Previously I had no need for snapshots in oss.sonatype.org but now I do. I'm getting an error saying that the dependency can't be found meaning that travis-ci I assume does not use it as the default maven repo. How can I tell travis to use oss.sonatype.org as well as its default repo's setup?
edit 1: Upon further investigation i found that travis is apparently setup to use central and sonatype mirrors so i'm not sure what's going on at all.
https://travis-ci.org/FINRAOS/herd/builds/298071150
Today while doing the release of our project, the release:perform command failed in between as our nexus was having intermittent issues. The release command only able to upload one pom file to nexus.
Now, the nexus issue is resolved and I am trying to do the release, it fails as the pom file already exists and its not the snapshot version and we don't have access to nexus so that I can delete that file and start over again.
Is there any way I can pass an argument so that release:perform should continue if the file is already there and ignore this but continue with uploading the rest.
I have looked for options of such type but didn't find anything.
My last resource would be to start the release again, which will bump the version number, but would like to understand if there is any other approach where in I don't need to bump the version.
I am using maven 2.2.1
Here's how I have handled this in the past. The release:perform command does a checkout of the tag from your SCM provider (e.g. SVN). This is done in the target/checkout directory of that project - whatever is there should be an exact copy of the released tag, so it will have the right version number in the pom files etc.
If you move to that directory (target/checkout in the directory where you started the release), you can simply do a mvn deploy there and it should compile and package that version, and then upload it to your Nexus instance.
If you don't have the target/checkout directory, you can check out the Tag created as part of the release:prepare phase from your SCM system to a fresh directory and run mvn deploy there.
Since the tag in your SCM has already been created, the only thing that's left is really compiling, packaging and deploying the release, which is exactly what mvn deploy should do.
If you have provided additional parameters (e.g. for activating profiles) for the build during the call to mvn release:perform, you will have to provide these as well when you run mvn deploy.
Using this approach, your version number will not have to change, it can stay the same, since you're just uploading what has already been tagged as part of mvn release:prepare.
My advice would be for you to request from the admins that the old artifact be removed. You can either re-deploy the code from the tag by checking it out and simply doing
mvn deploy
Or rolling back your release:
mvn release:rollback
And re-doing it as usual.
It is essential to remove the old artifact from the remote repository, if the sizes do not match. Release repositories do not allow the redeployment of artifacts, unless this has been explicitly switched on on the server side.
Furthermore, #nwinkler's answer is also quite good.