user3267761
user3267761

Reputation: 71

Jenkins / Maven Multi-Module with submodule build, fails the release build

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

Answers (2)

Robert Franz
Robert Franz

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

xeraa
xeraa

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

Related Questions