I'm running Jenkins 2.319.3 with a ton of Maven Project jobs. I recently learned that "The Jenkins project recommends that users transition from the Maven job type to use Pipeline jobs or freestyle jobs" and "Note that dependency version ranges are not supported, see JENKINS-2787 for the reason."
Source: legacy Maven Integration job type
I have reviewed both Pipeline Maven Integration and their related FAQ, and cannot find any mention of whether or not version ranges are supported for the downstream dependency trigger capability.
I would be using pipeline-maven plugin version 1235.v2db_ddd9f797b to transition from my legacy Maven Integration job type projects.
Are dependency version ranges supported for the pipeline-maven plugin, to trigger a build whenever a -SNAPSHOT dependency is built?
For example, project B with a dependency on project A using version range "[1.12,2.0)" is expected to be triggered when a build of upstream project A occurs that creates version 1.13.1-SNAPSHOT of A.
Related
Is there a way to determine that a new SNAPSHOT version of a dependency is available in a Nexus? Ideally it would be a command line that would take as input a group/artifact/version and would return true if it is the case.
Say I have mygroup.b1:1.0.0-SNAPSHOT which has as dependency mygroup.a1:1.0.0-SNAPSHOT, both version controlled and managed by my continuous deployment environment.
I would like for a build of mygroup.b1:1.0.0-SNAPSHOT to be triggered when a new SNAPSHOT of mygroup.a1 has been deployed in Nexus.
In my case, the continuous environment is GOCD Thoughtworks and I would like to trigger a pipeline based on the dependencies defined in a pom.xml file (that of mygroup.b1), some of which are SNAPSHOTs (such as mygroup.a1) that other pipelines could deploy.
I have looked at https://github.com/jenkinsci/maven-dependency-update-trigger-plugin which seems to do this by checking a dependency is downloaded when it is resolved. Since this is a Jenkins plugin it is not exactly what I am looking for.
I have also looked at https://github.com/aresok/go-maven-poller but the process seems tedious: is it required to define all dependent packages so that GOCD can poll Nexus?
Another thing is the usage of the versions:display-dependency-updates goal of the versions-maven-plugin http://www.mojohaus.org/versions-maven-plugin/display-dependency-updates-mojo.html but it does not seem to allow filtering on gav.
EDIT: added an example
EDIT: added information on the usage of the maven-versions-plugin
I've written a Maven plugin which we're using as part of our release process - as well as the usual release basically does some extra admin. I'd like to use this plugin for releasing the plugin itself but I'm not sure this is possible.
If I include the plugin in its own POM, using ${version} as the version number then I can't release because before deploying the release build it can't find the release build in the Nexus repo. If I use an earlier version, I get a clash (I don't think Maven likes two versions of the same project at once) and I'm not having any luck using a 'provided' scope as the plugin tag doesn't support this.
Is what I'm trying to do possible or should I resign myself to having a different release procedure for the plugin itself?
Thanks,
-Dave
I need to increment the project and subprojects release version , whitout create the new SNAPSHOT version.
I tried to use the Maven release plugin, but i found some incompatibility with my scm.
There are a plugin for only increment de buildnumber of a release named like 1.0-buildnumber?
I think I have wrongly interpreted the functions of the plug-in versions.
I did some tests, and I understand that this plugin allows you to update the pom.xml if the respective release has already been published.
This is not my case, what I need instead is to increase the release by increasing the BuildNumber so that the next phase of development can work using a new version of the project and subprojects.
I understand that this thing can be done only with the Maven release-plugin, but only in the context of using a scm.
If so,Thanks anyway for the support and sorry if I wasted your time.
In my current maven project I have a lot of submodules. I need to build a release and deploy it to my nexus...
Now I am facing the challange that I need for some of the modules differing version numbers. How can I handle this by usage of the release & deploy plugin? Or do I need some other maven plugins??? I configured the release plugin inside the parant pom. Is there a possibility to disable for example the "autoVersionSubmodules" for some of the submodules? Any ideas???
If you have a multi-module build than all modules should have the same version number otherwise it's an indicator that the multi-module build is not the right choice.
I am trying to define a release process for our project.
I was able to use the maven release plugin to accomplish the release but I had to manually update all of our internal SNAPSHOT dependencies to release versions prior to the prepare and then again back to SNAPSHOT versions after the release.
I have used the maven versions plugin and it detects my corporate dependencies that are SNAPSHOT builds and lists the correct release build to use.
I tried the maven release plugin, prepare goal, and complains about the SNAPSHOT versions in my dependencies.
Is there a way to do a release that updates the SNAPSHOT depenedencies to latest released versions and then back to SNAPSHOT versions after the release? Or maybe this is just not the way you are supposed to be using maven with releases and SNAPSHOTS.
When you create a realease with maven: it must be definitive. i.e. once it is created it cannot change anymore (i.e. the sources cannot change and the dependencies cannot change).
So when you create a release of moduleA and moduleA having a dependency on moduleB. moduleB must be released before moduleA is released, and moduleA MUST depends on a released version of moduleB.
One important thing is that you shouldn't go back to SNAPSHOT version. At least as I understand it means :
create moduleB-1.0.0 release
changing dependency to moduleB-1.0.0
create moduleA-1.0.0 release
then change the dependency back to moduleB-1.0.0-SNAPSHOT
It must be clear that once moduleB-1.0.0 exists (i.e. is released): the artifact moduleB-1.0.0-SNAPSHOT shouldn't be used anymore.
Instead of go back to SNAPSHOT should update dependency to next SNAPSHOT version (for instance moduleB-SNAPSHOT-1.0.1)
That being said, releasing a module depending on many SNAPSHOT artifacts is not an easy process, since every dependency must be released prior to releasing your main artifact.
What we have, most of the time, is a main artifact depending on many other artifacts (let's call them the corporate-modules) having the same versionning strategy. And so you can define a property corporate-module-version holding the version used by many dependencies in one place.
The release process is the following:
release every snapshot dependency with version number 1.0.0 (using the maven-release-plugin: after this step all pom.xml of your corporate-module in SCM are 1.0.1-SNAPSHOT) (see important remark at the end of this post to facilitate this step)
manually changing the corporate-module-version property to "1.0.0" in the main artifact (so that all SNAPSHOT dependencies are replaced by just released versions)
commit the modified pom.xml holding the corporate-module-version
with maven-release-plugin: releasing the main artifact (and after that, the new version in the SCM will be something like 1.0.1-SNAPSHOT)
manually changing the corporate-module-version property to "1.0.1-SNAPSHOT" in the main artifact (so that all dependencies are replaced by latest snapshot versions)
Important remark: having a multi-module parent project holding all your corporate modules is a must to perform at once the release of of all corporate modules. To not having too much trouble with the maven-release-plugin and the multi-module parent project be sure to put your parent pom.xml one directory upper all your child pom.xml (it's the designed recommend by maven, but unfortunately, sometimes, eclipse users don't follow it because eclipse don't like hierarchical projects)