Reputation: 71
I have a Jenkins / Maven / Git Multi-Module project that contains a submodule within (developed by contractors and nothing can change it). Because of Git and the submodule I have to clone the repo in my Linux, using the command "git clone --recursive ssh://xxxxxxx.git".
That means that I have to check-off the Jenkins Git plugin option of 'Advanced sub-modules behaviours' and 'Recursively update submodules' so that all the modules are populated (otherwise the submodule remains empty).
So I more or less has this type of configuration:
ParentDir Module 1 pom.xml Module 2 pom.xml ... Module n pom.xml Submodule pom.xml pom.xml
Everything builds fine in Jenkins for normal building('mvn clean install'). The problem happens only when trying to build the release build
The submodule is set to a specific version - 3.3.3-SNAPSHOT and can't be changed. Other modules that depend on this submodule have the dependency set to version 3.3.3-SNAPSHOT. Unfortunately, when the command:
mvn release:prepare -DreleaseVersion=0.1.2-test -DdevelopmentVersion=1.0.1-SNAPSHOT
Jenkins modifies all the pom files in each module in the project including the submodule. At that point, when maven tries to build there is no submodule version 0.1.2-test and everything dies. When I do a diff on the files that Jenkins left compared to what is inside our Repository I see:
>/opt/tools/bin/git diff pom.xml | cat
diff --git a/pom.xml b/pom.xml
index 5e4cc3c..2ac2db6 100644
--- a/pom.xml
+++ b/pom.xml
<artifactId>workingLib</artifactId>
- <version>3.3.3-SNAPSHOT</version>
+ <version>0.1.2-test</version>
<packaging>pom</packaging>
Is there a way to tell Jenkins/Maven not to update the submodule but update all the other modules?
Thanks,
Kevin
Upvotes: 0
Views: 3877
Reputation: 543
Trying to "hack" maven conventions is always a bad idea. Maven really reacts allergic when doing this. Either you are satisfied with mavens default behaviour or not. In case you are not then try to write an own release plugin. The standard release plugin increases all versions by default. There is no way out of that behaviour.
In my opinion the default way releasing with maven isn't really good. Especially in multi module projects it's a mess. Myself I wrote a shell script that simply does the following steps:
mvn versions:set
mvn clean install
git add
git commit
git tag
mvn deploy
mvn versions:set # now to next snapshot
git add
git commit
git push
Simply extend it and so on ...
Upvotes: 0
Reputation: 10859
All modules inside a parent POM share one version number. If a module follows a different release cycle / is not under your control, don't make it a module. Build and release it on its own and include it as a dependency.
Don't try to work around Maven's conventions — the tools won't support that well and you will run into issues.
Upvotes: 0