You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Stephen Woods <sw...@gmail.com> on 2009/03/25 19:12:12 UTC

Conflict managers - using revConstraints?

I have some questions about conflict managers...
 Here's my situation

   - Module A has a dependency to Spring revision "[2.0.2, )"... essentially
   indicating that it can use version "2.0.2" or later of Spring.
   - Module A is published to a shared repository, and the revision is
   set to "2.5.6" (because that is the latest in the repository at that time)
   with a revConstraint of "[2.0.2,)".
   - Module B is dependent on Module A
   - Module B has a dependency to Spring revision "2.0.2"... essentially
   indicating that is can only be used with version 2.0.2.
   - I set a latestCompatible conflict manager on Spring

Now, what I would hope that would happen is that Spring 2.0.2 would be
ultimately selected since its the latest version that is compatible between
both Module A and B. But that's not what happens... Instead, it appears that
since the published Module A has a revision of 2.5.6, it gets blacklisted
out right, and the build fails because Ivy says there are no compatible
versions between Module A and B.

So my questions are... is there another conflict manager that I should
consider using (i.e. something that takes into consideration the
revConstraint)? If not, is the Ivy conflict manager framework sufficiently
flexible enough to allow me to write my own conflict manager to handle this
situation (I stepped through the latestCompatible conflict manager with a
debugger and it looked pretty hairy)? Is there any documentation out there
that explains how conflict managers work (other than the code and the
official ivy docs)?

Though this may only be impacting me at the moment, I think this is a
showstopper for anyone attempting to use Ivy in an environment with
any transitive version conflicts.

Any insight would be greatly appreciated. Thanks!

Steve

Re: Conflict managers - using revConstraints?

Posted by Stephen Woods <sw...@gmail.com>.
Maarten,
I got really excited when I saw your message last night figuring that that
would make all the difference in the world... but alas... when I attempted
to do what you suggested, I received a java.lang.StackOverflowError.

I'm going to hook it up to a debugger and step through it to see what's
going on... I do think that's the right idea though. Thanks for pointing me
in the right direction!

Steve

On Wed, Mar 25, 2009 at 7:23 PM, Maarten Coene <ma...@yahoo.com>wrote:

>
> Steve,
>
> I don't know if it will solve your problem, but could you set your
> resolveMode to "dynamic"? This will tell Ivy to use the revConstraint
> attribute rather than the revision attribute.
> <ivy:resolve resolveMode="dynamic" ... />
>
> Maarten
>
>
>
>
> ----- Original Message ----
> From: Stephen Woods <sw...@gmail.com>
> To: ivy-user <iv...@ant.apache.org>
> Sent: Wednesday, March 25, 2009 7:12:12 PM
> Subject: Conflict managers - using revConstraints?
>
> I have some questions about conflict managers...
> Here's my situation
>
>   - Module A has a dependency to Spring revision "[2.0.2, )"... essentially
>   indicating that it can use version "2.0.2" or later of Spring.
>   - Module A is published to a shared repository, and the revision is
>   set to "2.5.6" (because that is the latest in the repository at that
> time)
>   with a revConstraint of "[2.0.2,)".
>   - Module B is dependent on Module A
>   - Module B has a dependency to Spring revision "2.0.2"... essentially
>   indicating that is can only be used with version 2.0.2.
>   - I set a latestCompatible conflict manager on Spring
>
> Now, what I would hope that would happen is that Spring 2.0.2 would be
> ultimately selected since its the latest version that is compatible between
> both Module A and B. But that's not what happens... Instead, it appears
> that
> since the published Module A has a revision of 2.5.6, it gets blacklisted
> out right, and the build fails because Ivy says there are no compatible
> versions between Module A and B.
>
> So my questions are... is there another conflict manager that I should
> consider using (i.e. something that takes into consideration the
> revConstraint)? If not, is the Ivy conflict manager framework sufficiently
> flexible enough to allow me to write my own conflict manager to handle this
> situation (I stepped through the latestCompatible conflict manager with a
> debugger and it looked pretty hairy)? Is there any documentation out there
> that explains how conflict managers work (other than the code and the
> official ivy docs)?
>
> Though this may only be impacting me at the moment, I think this is a
> showstopper for anyone attempting to use Ivy in an environment with
> any transitive version conflicts.
>
> Any insight would be greatly appreciated. Thanks!
>
> Steve
>
>
>
>
>

Re: Conflict managers - using revConstraints?

Posted by Maarten Coene <ma...@yahoo.com>.
Steve,

I don't know if it will solve your problem, but could you set your resolveMode to "dynamic"? This will tell Ivy to use the revConstraint attribute rather than the revision attribute.
<ivy:resolve resolveMode="dynamic" ... />

Maarten




----- Original Message ----
From: Stephen Woods <sw...@gmail.com>
To: ivy-user <iv...@ant.apache.org>
Sent: Wednesday, March 25, 2009 7:12:12 PM
Subject: Conflict managers - using revConstraints?

I have some questions about conflict managers...
Here's my situation

   - Module A has a dependency to Spring revision "[2.0.2, )"... essentially
   indicating that it can use version "2.0.2" or later of Spring.
   - Module A is published to a shared repository, and the revision is
   set to "2.5.6" (because that is the latest in the repository at that time)
   with a revConstraint of "[2.0.2,)".
   - Module B is dependent on Module A
   - Module B has a dependency to Spring revision "2.0.2"... essentially
   indicating that is can only be used with version 2.0.2.
   - I set a latestCompatible conflict manager on Spring

Now, what I would hope that would happen is that Spring 2.0.2 would be
ultimately selected since its the latest version that is compatible between
both Module A and B. But that's not what happens... Instead, it appears that
since the published Module A has a revision of 2.5.6, it gets blacklisted
out right, and the build fails because Ivy says there are no compatible
versions between Module A and B.

So my questions are... is there another conflict manager that I should
consider using (i.e. something that takes into consideration the
revConstraint)? If not, is the Ivy conflict manager framework sufficiently
flexible enough to allow me to write my own conflict manager to handle this
situation (I stepped through the latestCompatible conflict manager with a
debugger and it looked pretty hairy)? Is there any documentation out there
that explains how conflict managers work (other than the code and the
official ivy docs)?

Though this may only be impacting me at the moment, I think this is a
showstopper for anyone attempting to use Ivy in an environment with
any transitive version conflicts.

Any insight would be greatly appreciated. Thanks!

Steve