0

I'm trying to design a solution that allows a single Virgo application to provide backwards compatibility for integrating with multiple versions of an external service provider.

For example, the application, call it PortalApp, is a portal that currently integrates with version 2.3 of ThirdPartyApp. ThirdPartyApp v3.0 is coming out soon with new features, so the new version of PortalApp will have features that won't work with the older version of ThirdPartyApp.

I don't require being able to serve both versions dynamically at run time, just one or the other. I've already established that I can have two versions of a module in the Virgo usr repository, and load one or the other based on the .plan file used at server start.

For simplicity, we can assume project is currently set up like this:

PortalApp
- web-app
- ThirdPartyProvider

There are a number of other modules that depend on ThirdPartyProvider, so changing the ArtifactId would break those chains. What I'd like to do is build two different versions of the same module. Something like this:

PortalApp
- web-app
- - 1.0
- - 2.0
- ThirdPartyProvider
- - 1.0
- - 2.0

I tried creating a parent pom.xml in web-app (packaging: pom) that identified both 1.0 and 2.0 as modules, but only one of them builds.

Can a single build of the PortalApp project build both versions of a module?

Software Engineer
  • 15,457
  • 7
  • 74
  • 102
Tweeds
  • 1
  • 1
  • Why would you like to build 2 versions? one for version 2.3 and the other one for 3.0 which is coming? – Eddú Meléndez Feb 03 '15 at 03:24
  • Yes. That's it exactly, Eddú. The trouble spot is the requirement to continue adding functionality to both versions. Otherwise, I could archive the old module and add an assembly step to move it into the Virgo usr repository. – Tweeds Feb 04 '15 at 13:48

2 Answers2

0

No, it's not possible (actually it is, but you really wouldn't want to do that because it's a world of pain). The pom has a version tag and this is the version of the artifact that is built.

Rather than do that, you should create a multi-module project, with one module for each web-app, as you have in your second diagram, each depending on the relevant version of the ThirdPartyProvider. You would then factor out the common code from these web-apps - usually this produces two things, a common web-app which you depend on from web-app:1 and web-app:2 (this will create what's called an 'overlay' which pushes the contents of common into the other two apps, but which doesn't overwrite existing files), and a shared java library containing the common java classes (depending on how you use the third-party api you may need two of these too).

You then build both web-apps, producing two artifacts, web-app-1.war and web-app-2.war, each with a dependency on the relevant ThridPartyProvider and on the common classes lib.

Software Engineer
  • 15,457
  • 7
  • 74
  • 102
  • Thanks Engineer. That's sorta what I was expecting. I was hoping I missed a trick or exploit in the Maven, but figured I'd end up having to implement separate top-level poms for each released version. – Tweeds Feb 04 '15 at 13:44
0

In order to keep all artifacts in the same version you could use Versions Maven Plugin to set the version 2.0 or 3.0 and in your build you can use mvn package -DthirdParty.version=3.0

Make sure your pom.xml looks like this

<properties>
    <thirdParty.version>2.0</thirdParty.version>
</properties>

So you can use Jenkins in order to automate buils and ensure that eveyrhing is ok in your Continuous Integration process.

Eddú Meléndez
  • 6,107
  • 1
  • 26
  • 35