"mvn versions:use-releases (mvn goals)" remove the "SNAPSHOT" word on your dependencies, ONLY / DURING the specific build you've triggered, not modifying or parsing your pom.xml on the repo itself (like gitlab) this could be very helpful when using artifactory release management plugin because this process doesn't allow projects with SNAPSHOT word on pom.xml, however I have tried using the mvn versions:use-releases when doing a release on artifactory release plugin, but the build is failing due to the build read 1st the pom.xml (with snapshot) before executing the mvn goals that will remove the snapshot word, even I tried to put the mvn goals on the alternative maven goals and options under "enable artifactory release management"
is there any way to solve this?
Related
I added to my maven project the a PMD and checkstyle plugins. And when I run them the work perfectly. But when I remove them from the pom.xml I can still run mvn checkstyle:checkstyle or mvn pmd:pmd even though I removed them. Also after removing them I ran mvn clean install. ANy idea of what could happen ?
The commands you execute are plugin goals (plugin:goal) and unlike "mvn install" not a phase.
you can run almost any plugin on a project if maven can find it. The apache maven plugins allow that shortcut notation (pmd:pmd) since maven will try to resolve them in the apache namespace.
Plugins from other sources would need to be run with their full name, for example:
org.codehaus.mojo:versions-maven-plugin:2.5:display-dependency-updates
The plugin itself decides if it can run a goal on its own or if it requires a running reactor and only works within the maven life-cycle (usually because it depends on outputs from other phases)
So in your case: mvn install should not run the pmd plugin anymore if its not in the pom - and install is a phase. mvn pmd:pmd will run it directly with its default config - since pmd:pmd is a plugin goal.
The default plugins per packaging and phase are documented here. These may run if in the pom or not (depending on whats in the project).
How can I fail the build if a certain artifact does exist in the repository? The Maven Wagon Plugin has an "exists" goal, but not the opposite.
The reason for my question is as follows.
My Maven project goes through an automated build pipeline, which ends in a release stage. This stage performs an automated release through a mvn deploy -P release, after setting the release version with a mvn versions:set -DremoveSnapshot. The stage is triggered manually (since not every push should result in a release).
The mvn deploy will fail if the artifact to be uploaded is already in the repository. But this failure would come very late, during the last stage of the pipeline, while existence in the repository could be checked much earlier.
In order to get fail-fast behavior I would like to check if the artifact that would be released has not already been uploaded to Nexus. I want to do this in the first stage of the pipeline, which only performs a mvn package -P releasable. Preferably the "releasable" profile would make Maven do this check automatically during the "validate" phase of the default lifecycle.
The mvn deploy will fail if the artifact to be uploaded is already in the repository
Note: only if you upload as a "RELEASE", not a "SNAPSHOT".
Your build could check first if that release version exists:
mvn dependency:get -Dartifact=g:a:v -o -DrepoUrl=file://path/to/your/repo
If that gav (group-artifact-version) does exists, then you don't proceed with the rest of the build.
To keep that in a pom.xml, you can use:
activation profile, activated by a properties.
said property would be set by a first build step (or even before in the lifecycle) call to mvn dependency:get using the maven-dependency-plugin task.
dependency:get simply puts the artifact in the local repository if it exists.
I'm not sure how to fail the build from that point, since checking the local repo is not good enough.
You can check if the dependency artifact exists in the local maven repo.
I am new to maven and I'm using the maven release plugin to do a release and the maven deploy to deploy it. What I am noticing is that when I do
mvn release:prepare it makes two commits, as it should be, with the first one being without the snapshot in the pom.xml and then a newer version in the pom.xml with the snapshot. However when I then do mvn deploy it deploys the snapshot jar to my internal repository. How will I get it to deploy the release version of my jar? Should I be checking out HEAD~1 and then do mvn deploy?
Your question is slightly unclear, but the goal to run after release:prepare is release:perform.
Depending on what you're trying to do, the install or deploy plugins may also be useful.
Sonatype, the people that run Maven Central, have a very helpful guide to using the release plugin, as well as other ways of releasing:
http://central.sonatype.org/pages/apache-maven.html#performing-a-release-deployment-with-the-maven-release-plugin
I have a large Maven project in Jenkins. It consists of a parent project, and about a dozen local projects. Using Jenkins, I am able to do mvndeploy` and for the build to successfully deploy to my Artifactory repository.
However, I can't seem to get the Jenkin's Artifactory plugin to work itself to work.
My Artifactory setting in Jenkins:
And here's the setting for our job:
When using the Jenkins Artifactory Plugin you should execute mvn install instead of mvn deploy.
This is because the plugin collects the published artifacts from Maven and when executing mvn deploy directly you are kind of by-passing it's behavior.
Use Build Step "Invoke Artifactory Maven 3" when working with Artifactory plugin. And most preferably use goals "clean install"
I had the same problem and resolved by adding details under Build Environment -> Generic-Artifactory Integration as shown in below image
Published Artifacts now started uploading into desired location in artifactory.
In Jenkins (latest), Maven 3.0.x, I have a project (Java source code).
I'm using M2 release plugin, which provides a nice "Perform Maven Release" button on the Jenkins job (left hand side pane on the Jenkins job's dashboard). Behind the scene / in Jenkins job's configuration, it calls: release:prepare release:perform goals.
When I'm click on "Perform Maven Release", it does it's job successfully (builds from 1.0.0-SNAPSHOT, run tests && if successful, make changes to pom.xml and put version as 1.0.0 as version ID, perform some more verification and make changes to pom.xml (what maven-release-plugin checks are etc), commit this change in version control, tag it with 1.0.0 as a "TAG" in version control, change pom.xml again to use 1.0.1-SNAPSHOT and commit it, then checkout from that tagged 1.0.0 release version tag which we just created, checkout it under /target/checkout folder, build relase 1.0.0 artifacts (jar/war/pom etc) and finally deploys it to the repository which you'd have mentioned inside ..... ... section.
<distributionManagement>
<repository>
<id>dev-artifactory</id>
<url>http://1.2.3.15:8081/artifactory/libs-release-local/</url>
</repository>
<snapshotRepository>
<id>dev-artifactory</id>
<url>http://1.2.3.15:8081/artifactory/libs-snapshot-local/</url>
</snapshotRepository>
</distributionManagement>
What I need is:
1) How can I make "Perform Maven Release" process to call a deployment to a server once x.x.x release artifacts are generated by the process above and run some Integration tests. This should happen before deployment of artifacts to a binary repository (Artifactory/Nexus) is performed by maven-release-plugin process. i.e. if you are putting artifacts in a release repository, then non-unit tests are also successful (not that artifacts are in libs-release-local repository in Artifactory and Integration tests are yet to be launched.
OR do I need to change ... to use libs-snapshot-local (Artifactory repository) and then run IT tests and finally if those tests are successful, move 1.0.0 release artifacts from libs-stage-local repository to libs-release-local repository.
I know I can put maven-release-plugin related settings in Maven's user's .m2/settings.xml (user global) or at M2_HOME/.m2/settings.xml (global) but at this point, that's not the question.
We have a Jenkins deployment for each environment (dev, qa, prod). We move the same artifacts across all environments using Promoted Builds, Copy Artifact, and Parameterized Trigger plugins. To see how they work together, read this post (How to promote a specific build number from another job in Jenkins?)
As per the release process, instead of Maven Release plugin, use Maven Promote plugin (http://java.jiderhamn.se/2016/05/04/announcing-maven-promote-plugin/) to release the artifact that is already built and tested (there are a lot of articles on maven release plugin's drawbacks). You can still use Jenkins M2 Release Plugin, but in it's configuration, Release goals and options, call mvn release:clean promote:prepare release:prepare instead. For more details: https://github.com/mjiderhamn/promote-maven-plugin/issues/2
Maybe you should consider taking a look at this article here: https://pragmaticintegrator.wordpress.com/2014/05/12/running-the-maven-release-plugin-with-jenkins/
With Jenkins Release plugin you could customize your release workflow to add specific steps once your M2 release is done.