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?
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>
4
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.
3
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 }}