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 <[email protected]> wrote:

> Le 13 août 2010 17:35:50 UTC+2, C. Benson Manica <[email protected]> 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
[email protected]

Reply via email to