Maven with Jenkins – Update parent pom version of dependency
I have a pom file that looks similar to this
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>myApp</groupId> <artifactId>myAppId</artifactId> <packaging>war</packaging> <version>1.2-SNAPSHOT</version> <name>Maven Test Webapp</name> <url>http://maven.apache.org</url> <dependency> <groupId>com.manydesigns</groupId> <artifactId>portofino-war</artifactId> <version>3.1.10</version> <type>war</type> <scope>compile</scope> </dependency> </dependencies> <build> <finalName>TestName</finalName> </build> </project>
If i run ‘mvn release:prepare’ on the above pom file, the version of the artifact changes. i.e. it becomes
Now lets say i have gone and updated the portofino-war application which is a dependency of this pom file. portofino-war is now at version 3.1.11 but the parent pom file points to version 3.1.10 as shown above.
Is there any way i can update the parent pom (either via Maven or Jenkins) file if a new version of portofino-war is built?
The application uses Maven overlays – http://maven.apache.org/plugins/maven-war-plugin/overlays.html to build a war file from other war files. This means that if any of the dependent modules are built, the parent module has to be built to produce the final war file.
The problem is that at the moment if i build any of the modules, i have to manually update the version in the parent pom file to build using the correct module version.
Thanks for your help Ralph. Basically this is what i would like to achieve:
What i am trying to do is create a maven project that will build a war file based on several modules. Assume the modules have the following structure:
customerModule |-webapp |-jsp |-customer |-findCustomer.jsp |-addNewCustomer.jsp |-deleteCustomer.jsp |-src |-com |-mycompany |-customer |-FindCustomerAction.java |-AddCustomerAction.java |-DeleteCustomer.java
productModule |-webapp |-jsp |-product |-productCustomer.jsp |-addNewProduct.jsp |-deleteProduct.jsp |-src |-com |-mycompany |-product |-FindProductAction.java |-AddProductAction.java |-DeleteProduct.java
commonModule |-webapp |-css |-style.css |-jsp |-templates |-coreTemplate.jsp |-src com |-mycomany |-common |-Logger.java |-Access.java |-META-INF |-MANIFEST.MF |-context.xml |-WEB-INF |-lib |-oraclejdbc.lib |-log4j.lib |-common.lib |-struts-config.xml |-tiles-def.xml |-web.xml
Each of the modules shown will be developed by a different team. Each team produces a war file and installs it in the local maven repository. As an example the repository could look like this
com |-customerModule |-customerModule.v2.1.war |-customerModule.v3.0.war |-productModule |-productModule.v3.0.war |-productModule.v3.1.war |-commonModule |-commonModule.v0.5.war |-commonModule.v3.0.war
Now the build manager uses the above war files to build the final deployable war file. I was originally planning to use maven overlays to merge the three war files. I did test the merging of war files with overlays and found that the following configuration worked. i.e. using dependencies:
Note: These dependencies are in the commonModule pom file
<dependency> <groupId>com</groupId> <artifactId>customerModule</artifactId> <version>3.0</version> <type>war</type> <scope>compile</scope> </dependency> <dependency> <groupId>com</groupId> <artifactId>productModule</artifactId> <version>3.1</version> <type>war</type> <scope>compile</scope> </dependency>
If i then build the commonModule module, i end up with one war file that contains all the contents of Module1, Module2 and Module3. Which ends up with something like this:
MyApp.war |-webapp |-css |-style.css |-jsp |-customer |-findCustomer.jsp |-addNewCustomer.jsp |-deleteCustomer.jsp |-product |-productCustomer.jsp |-addNewProduct.jsp |-deleteProduct.jsp |-templates |-coreTemplate.jsp |-META-INF |-MANIFEST.MF |-context.xml |-WEB-INF |-lib |-oraclejdbc.lib |-log4j.lib |-common.lib |-customerModule.jar |-productModule.jar |-classes |-com |-mycomany |-common |-Logger.class |-Access.class |-struts-config.xml |-tiles-def.xml |-web.xml
The above works but requires a bit of manual intervention for a full release. Here is an example of what would happen if a module is modified
Team 1 updating module 1
- Team 1 makes changes to module 1 and check in changes into CVS - Team 1 installs module 1 onto the maven repository by issuing mvn:prepare and mvn:perform on module 1. This adds a new version of customerModule.war on to the local repository - Team 1 updates the dependency version for module 1 in the pom file used to merge the war files (i.e. commonModule) - Team 1 builds the deployable war file by building the commonModule.
The above does not use a multi module project as you suggested so i am trying to understand how the versioning would work with multi module projects. For example, lets say the multi module project will look like this
MyApp |- productModule |-pom.xml |- customerModule |-pom.xml |- commonModule |-pom.xml |-pom.xml
- What is the difference in adding the version number in each child module compared to just havin the version number on the parent?
- You say that the child modules will use the parent version. Lets say the parent version is currently version 3.4, how will it know that it is supposed to use version 3.1 of the productModule.war?
- And finally, if team 1 has made a change to one of the child modules, would they still need to build it and deploy it on to the maven repository as an individual product first before building the multi-module project or can this be done as one step?
- How would this work if i want to make a patch release that does not necessarily mean using the latest version of a specific module?
2 Solutions collect form web for “Maven with Jenkins – Update parent pom version of dependency”
For the scenario described in the “Edit” part of the question, I would recommend to put all war files in a single: multi module project.
You may want to use a dependency range instead of updating the pom: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges