I have a snapshot and a release repository defined in the pom.xml of all modules
The modules in my project may be developed and updated independently, i.e. one may be updated (and hence be -SNAPSHOT) during development whereas all others are untouched with release versions
My release nexus repository prevents redeployment
Running mvn deploy will successfully deploy -SNAPSHOT projects to the snapshot repository as required but when it tries to reploy one of the unchanged modules the build fails because that module is already in the release repository
I do not want releases to be redeployable - once a release is deployed it is final
Is there a way to run "mvn deploy" such that all snapshot bundles do get deployed but release modules are skipped?
Related
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 am actually searching for an solution on how to automatically release artifacts for my open source projects to maven central/our company nexus. I am using Maven/Gradle and Travis CI to build the artifacts.
Ideally i just change the version of my maven gradle module to an release version, travis recognizes that and deploys the resulting artifact to nexus/maven central.
Has anyone ideas how to do that without building releases locally.
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.
I am using Jenkins as CI environment and I want to have the ability to deploy the build artifacts directly to a JBoss AS 7.1.1 server. For releasing the Maven artifacts I am using the Jenkins M2 Release Plugin.
The project structure of the project which makes problems looks as follows:
artifact-parent-pom
webapp-module
theme-module
The maven goal jboss-as:deploy can only be called on webapp-module.
To deploy the webapp-module to the JBoss server on every build, I added a post-build step calling
mvn jboss-as:deploy
on the sub-module. This works perfectly for standard SNAPSHOT builds, but not for release builds.
When using the Jenkins M2 Release Plugin to release a new artifact version, the version number is already updated to the next SNAPSHOT-version when the post-build step is executed. I tried to deploy the release version directly at the release step, but this doesn't work, hence the goal jboss-as:deploy cannot be called on the parent-pom.
All Jeknins plugins i have found only support older versions of JBoss like
Deploy to container Plugin
JBoss Management Plugin
Is there an easy way to get this working?
I have found a workaround. I made two configurations, one for the SNAPSHOTS and one for the RELEASE builds. At the RELEASE build I added two post-steps both calling the goal version:set on the parent-pom but with different properties. This results in the following post-steps:
mvn newVersion=${MVN_RELEASE_VERSION}
mvn jboss-as:deploy
mvn newVersion=${MVN_DEV_VERSION}
We use mvn deploy:deploy to deploy an artifact to repository manager and a developer could have done just mvn install for the same artifact, so the artifact is present under M2_HOME\.m2\repository
Will the maven runtime retrieve the artifact from the repository manager if it was updated recently than the local repository copy?
Note: We use a maven repository manager based on Apache Archiva.
The answer depends on whether you're talking about a snapshot or a release build.
Release builds have a version that doesn't end with "-SNAPSHOT", and they're final and immutable. Once installed to any repository, Maven will never update them. To your question, that means that if a dev installs a release build locally, it will never be updated from any remote repository.
Snapshot builds are always eligible to be updated from any repository. By default, Maven checks once per day for new snapshot versions, so if someone installs a snapshot locally, that snapshot will exist until Maven does its next check for snapshot updates. Then, if a newer version is in any remote repository it checks, the local one will be overwritten. You can force maven to update snapshot artifacts with the -U command line option.