maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Rueden <ctrue...@wisc.edu>
Subject Re: Use same jar (different version) in one project
Date Tue, 29 Nov 2016 18:05:36 GMT
> How to depend on the same jars with different versions in one project?

Maven's whole design is centered around each GA having only one associated
V. Hence, it performs dependency convergence during builds etc. You can do
a structure like Anders described, which will solve it at compile time, but
it does not address runtime deployment, where presumably you will have one
single classpath. You can of course put both versions of the library in
question on your classpath via some mechanism, but if you want to lean on
Maven for this, it will not be easy.

The solution I've seen which works well is to use a different artifactId
for the new version—as long as the classes are indeed different. For
example, Apache Commons Math 3 is org.apache.commons:commons-math3 [1],
whereas the older Commons Math 2 is org.apache.commons:commons-math [2].
This is really nice because then you can use both artifacts freely in a
single Maven project.

If you use a Maven repository manager in your organization, you can always
redeploy one of the project versions under a different GA in your
repository, and depend on that, so that Maven does the "right thing" for
your needs here.

Regards,
Curtis

[1]
http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.commons%22%20AND%20a%3A%22commons-math3%22
[2]
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.commons%22%20AND%20a%3A%22commons-math%22

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Mon, Nov 28, 2016 at 9:14 PM, big data <bigdatabase@outlook.com> wrote:

> Dear all,
>
> How to depend on the same jars with different versions in one project?
> Our project is used to deploy on different customer side, which has
> different jar version environments. The codes depends the jar, which has
> two different version 1.0 and 2.0, these two versions are not compatible
> (eash one has own unique API), so our code should support these two
> versions, and can build to different release package to support 1.0 or 2.0.
>
> how to configure pom to support this situation?
>
> Thanks.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message