1

I have 2 Maven artifacts with 2 versions, lets say A1, A2, B1, B2. B1 depends on A1, B2 depends on A2. A1 and A2 are very similar, lets say A1 is using Java 7 and A2 is using Java 8 and lambdas. All artifacts are used by our clients and sometimes they install the wrong artifact for their environment.

I want to build a base A artifact, A1 and A2 will inherit A and add custom functionality and another artifact, A_Client, and I want to choose at runtime based on some properties(JDK and some others) which Ax module should be used. This way, our clients will have to install A_Client and they will not have to worry about the right version.

B1 and B2 are the same, the only thing that's different is their Ax dependency. If I can merge A1 and A2 somehow, I will have only a B artifact available for clients that will depend only on A_Client. This way I will eliminate the B versions hell too.

So, the question: Is it possible to decide at runtime a dependency? My guess is that it may be possible using OSGi or custom Class loaders, but I have very limited knowledge in both areas so any help is appreciated.

Silviu Burcea
  • 5,103
  • 1
  • 29
  • 43
  • Note: the `provided` scope is designed for artifacts that will magically appear at runtime. I've no experience, however, with ensuring the right artifact is selected. I'll leave the answer to someone more knowledgeable. – Duncan Jones Dec 09 '13 at 15:27
  • 1
    Put your jars in a folder and add it to the classpath based on a certain property using something like: http://stackoverflow.com/questions/1010919/adding-files-to-java-classpath-at-runtime – ieugen Dec 09 '13 at 15:41

2 Answers2

0

Maven

Maven is a build tool, so it won't help you at runtime. It's possible to activate different profiles based on the used JDK, but it's based on system which builds it, not the system which runs it.

OSGI

I didn't use OSGI yet, but what I know is that it's a very different deployment and runtime model. It doesn't justify the effort, just to prevent your customers deploying the wrong version.

Deployment process

Not everything should be solved by a technical solution. Deploying the wrong artifact should definitely solved with an adjusted deployment process. Think about..

  • Why did they deploy the wrong artifact?
  • Do they have a documented deployment process? How should the process be changed?
  • Can you make the artifacts more distinguishable? Could you rename it?
  • Can you make it fail fast? It should fail to deploy, not when it's already in use.
Community
  • 1
  • 1
Christian Strempfer
  • 7,291
  • 6
  • 50
  • 75
0

This is an old question but deserves a modern answer that makes sense in the now-modular-JDK world.

What I really wanted in the original question is to have a JAR which could execute a different implementation, chosen at runtime, depending on the Java version I'm running. I've thought that Maven could do that, since there were no other options available. In the modular world, this is exactly what Multi-Release-Jars solves.

If Java version is not a problem, but there are 2 implementations which must be used based on a system property, application state or whatever, one could pack both of them as service implementations, add both of them in the module path and in the client load them via ServiceLoader and decide which implementation is needed at runtime.

Silviu Burcea
  • 5,103
  • 1
  • 29
  • 43