You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "C. Benson Manica" <cb...@gmail.com> on 2010/08/13 17:35:50 UTC
"Smart" transitive dependency resolution?
I have projects A, B, C, and D. A is basically a database API that a
variety of projects use. B depends on A, C depends on B and A, and D
depends on C and A. When building project D, I could therefore
theoretically end up with as many as three different versions of A - one
each from the transitive dependencies of B and C, and another one from D's
explicit dependency. What I want is for D to include the "latest" version
of A based on these three dependencies, so if B depends on A-3.1, C depends
on A-3.3, and D depends on A-3.2, the actual artifact on D's classpath will
be A-3.3. Obviously exclusions and optional dependencies don't really do
what I want, because I don't know which dependency on A is the "latest". Is
there a way to do anything remotely like this?
(Obviously, yes, I'm now aware that if this project were designed correctly,
there wouldn't be this web of transitive dependencies in the first place,
but fixing that isn't really possible at the moment.)
--
C. Benson Manica
cbmanica@gmail.com
Re: "Smart" transitive dependency resolution?
Posted by "C. Benson Manica" <cb...@gmail.com>.
I apologize for sounding harsh, it wasn't my intention. Anyway, I figured
what I wanted wasn't possible (because it *is* kind of a dumb situation). I
think I may end up making A an optional dependency in B and C after all, and
make D depend on the latest version. Thanks for the analysis.
On Sun, Aug 15, 2010 at 5:52 AM, Baptiste MATHUS <ml...@batmat.net> wrote:
> Le 13 août 2010 17:35:50 UTC+2, C. Benson Manica <cb...@gmail.com> a
> écrit :
>
> > I have projects A, B, C, and D. A is basically a database API that a
> > variety of projects use. B depends on A, C depends on B and A, and D
> > depends on C and A.
>
>
> A
> | \¯¯¯¯¯\
> B \ \
> \ \ \
> ¯C \
> ¯¯¯¯D
>
> > When building project D, I could therefore
> > theoretically end up with as many as three different versions of A - one
> >
> ???
> I don't see why. B depends on A, true, but A isn't built differently
> because
> it's used as a dependency by B or C or D.
> Have you seen hundreds of hibernate versions, since this project is used
> very often? Nope...
>
> each from the transitive dependencies of B and C, and another one from D's
> > explicit dependency. What I want is for D to include the "latest"
> version
> > of A based on these three dependencies, so if B depends on A-3.1, C
> depends
> > on A-3.3, and D depends on A-3.2, the actual artifact on D's classpath
> will
> > be A-3.3. Obviously exclusions and optional dependencies don't really do
> > what I want, because I don't know which dependency on A is the "latest".
> > Is
> > there a way to do anything remotely like this?
> >
>
> Well, I guess I know better understand what you'd like to do.
> In short, no, it's not possible since it's related to the artifact version
> resolution algorithm (shortest path to groupId/artifactId is the version to
> be used).
> The simplest solution is to repeat the wished GAV in the current artifact
> you want to build. I'm not sure there's a simple solution to handle this,
> apart from playing with variables/custom plugin. Without the fact that
> using
> variables in versions can be a bad practice for build reproducibility.
>
>
> >
> > (Obviously, yes, I'm now aware that if this project were designed
> > correctly,
> > there wouldn't be this web of transitive dependencies in the first place,
> > but fixing that isn't really possible at the moment.)
> >
>
> Well, having dependencies isn't a problem.
>
> Cheers.
> PS : would be a bit more polite to say hello, and end by thanks your
> request. This way is a bit harsh in my opinion.
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>
--
C. Benson Manica
cbmanica@gmail.com
Re: "Smart" transitive dependency resolution?
Posted by Baptiste MATHUS <ml...@batmat.net>.
Le 13 août 2010 17:35:50 UTC+2, C. Benson Manica <cb...@gmail.com> a
écrit :
> I have projects A, B, C, and D. A is basically a database API that a
> variety of projects use. B depends on A, C depends on B and A, and D
> depends on C and A.
A
| \¯¯¯¯¯\
B \ \
\ \ \
¯C \
¯¯¯¯D
> When building project D, I could therefore
> theoretically end up with as many as three different versions of A - one
>
???
I don't see why. B depends on A, true, but A isn't built differently because
it's used as a dependency by B or C or D.
Have you seen hundreds of hibernate versions, since this project is used
very often? Nope...
each from the transitive dependencies of B and C, and another one from D's
> explicit dependency. What I want is for D to include the "latest" version
> of A based on these three dependencies, so if B depends on A-3.1, C depends
> on A-3.3, and D depends on A-3.2, the actual artifact on D's classpath will
> be A-3.3. Obviously exclusions and optional dependencies don't really do
> what I want, because I don't know which dependency on A is the "latest".
> Is
> there a way to do anything remotely like this?
>
Well, I guess I know better understand what you'd like to do.
In short, no, it's not possible since it's related to the artifact version
resolution algorithm (shortest path to groupId/artifactId is the version to
be used).
The simplest solution is to repeat the wished GAV in the current artifact
you want to build. I'm not sure there's a simple solution to handle this,
apart from playing with variables/custom plugin. Without the fact that using
variables in versions can be a bad practice for build reproducibility.
>
> (Obviously, yes, I'm now aware that if this project were designed
> correctly,
> there wouldn't be this web of transitive dependencies in the first place,
> but fixing that isn't really possible at the moment.)
>
Well, having dependencies isn't a problem.
Cheers.
PS : would be a bit more polite to say hello, and end by thanks your
request. This way is a bit harsh in my opinion.
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Re: "Smart" transitive dependency resolution?
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 13/08/2010 11:35 AM, C. Benson Manica wrote:
> I have projects A, B, C, and D. A is basically a database API that a
> variety of projects use. B depends on A, C depends on B and A, and D
> depends on C and A. When building project D, I could therefore
> theoretically end up with as many as three different versions of A - one
> each from the transitive dependencies of B and C, and another one from D's
> explicit dependency. What I want is for D to include the "latest" version
> of A based on these three dependencies, so if B depends on A-3.1, C depends
> on A-3.3, and D depends on A-3.2, the actual artifact on D's classpath will
> be A-3.3. Obviously exclusions and optional dependencies don't really do
> what I want, because I don't know which dependency on A is the "latest". Is
> there a way to do anything remotely like this?
>
> (Obviously, yes, I'm now aware that if this project were designed correctly,
> there wouldn't be this web of transitive dependencies in the first place,
> but fixing that isn't really possible at the moment.)
>
Your underlying believe that A-3.1 and A-3.3 are all equally functional
for your projects is a bit hard to defend and I can see that you have
figured this out.
So much for the criticism, now some ideas.
Make a parent POM and add a dependency management section where you can
override the lower level POMs' version choices so you force everyone to
use A-3.3.
If you are just trying to avoid figuring out the latest version, you can
get help from Maven's dependency tree which will tell you if you have a
version conflict on an artifact in your tree and will tell you what
versions are involved and who is dragging in the old ones.
Then you can fix D to have the right version regardless of the lower
level POMS.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org