Supporting and testing multiple versions of a software library in a Maven project

Question

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?

score 4 · Accepted Answer · answered Nov 27 '12 at 12:03

4

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>

answered Nov 27 '12 at 12:03

Donal Fellows

6,347
25
35

Perfect. I had considered profiles earlier, but for some reason decided they weren't right. Clearly I was wrong! – Duncan Jones Nov 27 '12 at 12:05
Alternatively, I could use the profiles to set a property (`lib-build-version`) and include that in my main dependencies section. – Duncan Jones Nov 27 '12 at 12:08
@Duncan There are many options, depending on how much you need to tinker with the build for different versions. My builds tend to need much more surgery between versions than just a version number update… – Donal Fellows Nov 27 '12 at 13:07
Isn't it painful to have to define a separate profile for each version you want to test? I have proposed another solution which only uses a property that can be changed at will, it feels simpler but maybe I am missing something! – pintoch Apr 25 '23 at 13:14

score 0 · Answer 2 · answered Nov 26 '12 at 14:25

0

If it applies, you can create a branch in source control for each version and instruct your CI tool to build/test all active branch heads.

This may be problematic if you have an active branch that you do not want to build/test. You'd have to work it out based on your needs, but I would suggest you consider leveraging version control if possible.

answered Nov 26 '12 at 14:25

smp7d

4,201
1
22
40

I would prefer to maintain a single code trunk in my version control, if at all possible. I'd be concerned otherwise that changes to the trunk might not be merged into branches (or vice versa). Can you suggest a benefit to branching compared with, say, the second suggestion I outline above? – Duncan Jones Nov 26 '12 at 14:36
1

@DuncanJones Tough to tell based on your description. Seems like you would be managing many projects as opposed to branches of one project. – smp7d Nov 26 '12 at 18:55
I reread my question and I agree it was quite unclear. I've completed re-edited the question and would appreciate your thoughts. Please comment against the question if any sections are unclear. – Duncan Jones Nov 27 '12 at 09:16

pintoch · Answer 3 · 2023-04-25T13:17:31.403

You could just set the version of your dependency via a property defined in your pom.xml:

<properties>
   <core.version>3.4.5</core.version>
</properties>

<dependencies>
  <dependency>
    <groupId>com.foo</groupId>
    <artifactId>core-software</artifactId>
    <version>${core.version}</version>
  </dependency>
</dependencies>

This can then be overridden from the command-line at will:

mvn test -Dcore.version=3.6.8

You can then configure your CI so that it executes this command with various versions. For instance, with GitHub Actions:

jobs:

  build:
    strategy:
      matrix:
        core_version: ["3.4.5", "3.6.8", "4.2.0"]
    runs-on: ubuntu-latest

    steps:
    # (some other preliminary steps...)
    - name: Build with Maven
      run: mvn -B package -Dcore.version=${{ matrix.core_version }}

Supporting and testing multiple versions of a software library in a Maven project

3 Answers3