Maven Project – Supporting and Testing Multiple Versions of a Software Library

compatibilityjavamavenversioning

My company has several versions of its core software in use by our customers at any one time. My job is to write bespoke Java software for the customers based on the version of core software they happen to be running.

I've created a common Java library that performs many of the tasks I regularly require in a normal project. This is a Maven project that I deploy to our local Artifactory and pull down into other Maven projects when required.

Currently this library includes v1.3 of our core software, for example:

<dependency>
  <groupId>com.foo</groupId>
  <artifactId>core-software</artifactId>
  <version>1.3</version>
</dependency>

As a result, that's the only version I'm completely confident is compatible due to the success of the unit tests. How can I best automate testing with other versions of the core software to ensure compatibility?

One possibility is to create a series of Maven projects that incorporate my library and override the core-software version:

<!-- Override core version -->
<dependency>
  <groupId>com.foo</groupId>
  <artifactId>core-software</artifactId>
  <version>1.2</version>
</dependency>
<!-- Incorporate shared library: -->
<dependency>
  <groupId>com.foo</groupId>
  <artifactId>common-lib</artifactId>
  <version>1.0</version>
</dependency>

I could then execute the unit tests from my main project to ensure they all pass (I need to figure that bit out). The benefit of this approach is that I can incorporate these additional Maven projects in my continuous integration server and be alerted whenever a check-in breaks compatibility with another core software version.

Can anyone suggest a better alternative?

Best Answer

You could use multiple Maven profiles in your project, overriding the version of the core software in each profile. Then just get your CI software to build with each profile.

The profile might say this:

<profiles>
  <profile>
    <id>old</id>

    <!-- When this profile will turn on... -->
    <activation>
      <property>
        <name>buildVer</name>
        <value>old</value>
      </property>
    </activation>

    <!-- What this profile changes... -->
    <dependencies>
      <dependency>
        <groupId>com.foo</groupId>
        <artifactId>core-software</artifactId>
        <version>1.2</version>
      </dependency>
    </dependencies>
  </profile>

  <profile>
    <id>veryold</id>
    <activation>
      <property>
        <name>buildVer</name>
        <value>veryold</value>
      </property>
    </activation>
    <dependencies>
      <dependency>
        <groupId>com.foo</groupId>
        <artifactId>core-software</artifactId>
        <version>1.0</version>
      </dependency>
    </dependencies>
  </profile>
</profiles>

Related Solutions

Continuous Integration with Bamboo and Maven, Managing Version Numbers

I find using a snapshot approach using the maven snapshot functionality works fine out of the box.

Maven will automatically grab the latest snapshot release from the repository for a particular major/minor build number.

It then becomes only a matter of updating the major/minor version numbers when you do a release, and maven can do that for you as well through the maven::release command.

I normally use Jenkins/Hudson to build the release and upload the artefacts to the repository on completion of the build. I have used TeamCity before but find Jenkins a much more featured CI utility.

Maven Dependency Management – Sharing Configuration Over Multiple Projects

If I understand your situation clearly, it seems like you have many A type Maven artifacts, and these mostly all define a dependency to a few B type artifacts.

The A type artifacts are product of your development Group. The B type artifacts that A depends on are from an external Group. Your runtime environments for A type and B type Artifacts will have bundled into them the B Artifacts already.

The problem is that when the Version of a B Artifact changes on the server, you do not want to be hassled with manually updating many POM files with all of the dependency changes that happened in B initially.

Your first suggestion I think is the best approach:

I just thought about creating some kind of artifact, that contains all the dependencies that plugins like A could have.

You can absolutely do this and it is an accepted practice. What you do is define a parent POM file that declares all of the dependencies an A type Artifact could need. This parent POM file can be deployed to your Maven repository as it's own unique Group, Artifact and Versioned module. This parent POM module can then be referenced in your A type projects POM files using the <parent> element. The benefit is that you can update all of the B type plugin versions in the parent project and reversion just the parent POM. Now your A type POM's only need to update their version number if they are to get the new dependencies. For more information on Parent POM projects see below.

https://stackoverflow.com/questions/14400642/maven-parent-pom

The really bad thing (even if this would work) is that plugin A would have dependencies it does not really need.

But you see this isn't actually a bad thing!

<dependency>
  ...
  <scope>provided</compile>
</dependency>

Using the provided scope on a dependency to a B plugin is basically telling Maven that it is ONLY going to use this Artifact for compiling sources and unit testing. It will ignore the dependency specifically during packaging of the build artifact with the assumption that the JDK or the application container will provide this for the plugin during runtime.

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

If some of the dependencies aren't being used it won't matter. They won't be bundled, they are only downloaded and used to compile and run test cases.

Best Answer

Related Solutions

Continuous Integration with Bamboo and Maven, Managing Version Numbers

Maven Dependency Management – Sharing Configuration Over Multiple Projects

Related Topic