Background
I have two Grails applications, both running Grails 2.3.6 with the release plugin installed (build ":release:3.0.1").
I have a jenkins CI server setup to automatically pull the projects from source control and deploy the war to artifactory. From there, it can be automatically deployed to our tomcat server by a script.
For one application, the maven-metadata.xml file generated by Artifactory contains a <latest> tag, which specifies which of the versions of my application is the latest one.
Problem
My problem is, the other application doesn't have a <latest> tag, even though it's using the exact same command to deploy to our Artifactory repository-- grails maven-deploy. The BuildConfig.groovy files are basically identical.
This is a problem because I need that <latest> information to be available for my deployment script.
From what I've read around the web, the maven-metadata.xml file is generated by maven 2 only when the -DupdateReleaseInfo=true flag is set. However, I can't see any place that the working application is passing this flag to maven during the build.
I've tried the fix suggested on this thread-- namely,
Making sure that deploying user has "annotate" permission
Maven Snapshot Version Behavior = "Deployer"
But my second application still doesn't get a <latest> tag added to its maven-metadata.xml.
So, I figured out that I can easily just pass -DupdateReleaseInfo=true to the grails maven-deploy command as an additional argument, and that forces maven to update the <latest> tag in maven-metadata.xml. I'm not sure why it is doing it sometimes and not others, but at least it works!
Related
In out project we are using using deployed war file in /archiva-2.2.0/repositories/internal/com/xyz/1-SNAPSHOT/proj-1-20160204.122021-15.war path using shell script to copy to jboss. However finding the latest build timestamp and build number is very difficult. Is there a way to avoid using timestamp while storing it in archiva like proj-1-SNAPSHOT.war?
I have already read about <uniqueVersion>false</uniqueVersion> whcih is not supported in maven 3.
I am using archiva-2.2.0, maven-3.3.9.
Maven repositories wasn't designed to distribute deployable components, your continuous integration environment should take care of this. Jenkins has eg Archive Artifacts (native) and Copy Artifact Plugin which you can use to store and recover binaries in your pipelines.
But you can workaround this behavior changing the version of the war to a stable one - removing the -SNAPSHOT suffix. This will lead you with a predictable URL.
I am posting this as it is a new finding, if I wget http://xx.xx.xx.xx:8083/repository/internal/com/xyz/1-SNAPSHOT/proj-1-SNAPSHOT.war. I get the latest deployed artifact in the archiva repository. So archiva does a 302 redirect to point to url of http://xx.xx.xx.xx:8083/repository/internal/com/xyz/1-SNAPSHOT/proj-1-20160204.122021-15.war location and downloads the latest build. I am not sure if this works for other repositories like nexus or artifactory etc.
Ofcourse I will need a cron job to periodically clear of the stale snapshot artifacts.
We are using Jenkins to build (maven) & deploy artifacts (JARs & *WAR*s) to an in-house artifactory server (both snapshots and releases).
For deployment, currently, we got Jenkins jobs that package the war file (from a release scm tag) and deploy to different environments/servers. We want to skip the package phase as it seems unnecessary to package it again & again for a released version because it's not possible to get a different copy of war file even after trying 1000 times.
We are looking for a way in Jenkins to get the artifact (war) from Artifactory and deploy it to a container. I am sure other people would have faced this situation too but I am not able to find any online material regarding this.
Is there any Jenkins plugin that takes a war file from Artifactory (based on a version) and deploy it to a remote container?
If this is not the right way of doing it then what are the recommendations for any other approach?
Thanks
I don't know about a plugin which takes a version # and deploys that, but you can build a Jenkins job to deploy the last successful release to a previous environment (thus copying from DEV-->QA for example.)
To do this, you would use the copy-artifact-plugin.
Here's an easy to follow run-through of this kind of setup:
http://www.lordofthejars.com/2012/09/deploying-jee-artifacts-with-jenkins.html
Every artifact stored in Artifactory will have a unique URL that includes the version number. It will take the format
http://artifactory-server/repository-name/path-to-artifact/version/filename
e.g.
http://artifactory/apps-releases-local/com/yourorg/yourapp/1.5.67/webapp.war
(depending on how you do your packaging, the WAR file name may include the version number as well).
So your deployment job can construct the Artifactory URL and download the file. Depending on how you have security set up in Artifactory, you may need to authenticate the request.
I'm trying to set up a release plugin in a maven project but it fails at deployment of release artifacts in release:perform. The Nexus repository returns 400 and the maven log tells me that the binary is installed twice to my local repo and then also attempted to be uploaded twice.
I get the feeling that it's related to a custom (3rd party) packaging I'm using - but due to business reason I cannot reveal the name of this.
Anyone that think of a "typical" packaging error that would fool maven to install and deploy the jar twice? other artifacts like javadocs, sources etc do not suffer the sample problem.
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.
I want to create maven project in Netbeans. So, I do File->New project->Maven->Java Application. After that I try to build the project and get error:
The POM for org.apache.maven.plugins:maven-surefire-plugin:jar:2.10 is missing, no dependency information available.
But I can build this project from command line with mvn compile. Could uou tell me what is the problem with Netbeans?
NetBeans is using 3.0.4 maven by default. Unless you change that in Tools/Options menu. Are you building with 3.0.4 as well or are you using some earlier versions (2.x)?
That would explain the behaviour because 3.0.4 will not blindly rely on what artifact is in local repository but some additional metadata is also consulted to make sure your project build with the given set of defined repositories.
A common example when the problem occurs to me.
I use central directly everything downloads. when I later add a mirror, all artifacts are checked again through the mirror to make sure they are accessible. if teh Mirror doesn't actually mirror central, I get an error that way.
Another common example is: when building with 2.x, the additional metadata is not written, when later building with 3.0.4, all remote context is checked no matter what is present in local repo and the additional metadata files are constructed.