Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

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>
share|improve this answer
    
Perfect. I had considered profiles earlier, but for some reason decided they weren't right. Clearly I was wrong! –  Duncan 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 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
add comment

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.

share|improve this answer
    
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 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 Nov 27 '12 at 9:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.