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 "Crystal, Mayer" <ma...@gs.com> on 2007/12/06 16:46:48 UTC
Question about revision conflicts during resolve/retrieve
We are using Ivy 1.4.1 and had a question about conflict resolution
between 2 modules. Let's say we have a setup like:
A depends on B version 1.4 and C version 1.5
B depends on C version 1.+
Version C in the repository is 1.7
Is there a way to tell ivy that when it is resolving, if it comes across
a firm requirement (1.5 for C for module A) which doesn't conflict with
other requirements (the 1.+ for C for module B) to always choose the
strict requirement?
Thanks,
Mayer
RE: Question about revision conflicts during resolve/retrieve
Posted by Xavier Hanin <Xa...@sas.com>.
Do you mean backported? Very little chance, this conflict manager was pretty difficult to implement and required some changes in dependency resolution logic which has already been updated in 2.0 stream. But you have all the commit logs on the issue to see how it has been implemented, so feel free to backport the changes :-)
Xavier
> -----Original Message-----
> From: Crystal, Mayer [mailto:mayer.crystal@gs.com]
> Sent: Thursday, December 06, 2007 10:53 AM
> To: ivy-user@incubator.apache.org
> Subject: RE: Question about revision conflicts during resolve/retrieve
>
> This wouldn't by chance be backward compatible with 1.4, would it? :)
>
> -----Original Message-----
> From: Xavier Hanin [mailto:Xavier.Hanin@sas.com]
> Sent: Thursday, December 06, 2007 10:51 AM
> To: ivy-user@incubator.apache.org
> Subject: RE: Question about revision conflicts during resolve/retrieve
>
> > -----Original Message-----
> > From: Crystal, Mayer [mailto:mayer.crystal@gs.com]
> > Sent: Thursday, December 06, 2007 10:47 AM
> > To: ivy-user@incubator.apache.org
> > Cc: Etkine, Dmitri
> > Subject: Question about revision conflicts during resolve/retrieve
> >
> > We are using Ivy 1.4.1 and had a question about conflict resolution
> > between 2 modules. Let's say we have a setup like:
> >
> > A depends on B version 1.4 and C version 1.5 B depends on C version
> > 1.+ Version C in the repository is 1.7
> >
> >
> > Is there a way to tell ivy that when it is resolving, if it comes
> > across a firm requirement (1.5 for C for module A) which doesn't
> > conflict with other requirements (the 1.+ for C for module B) to
> > always choose the strict requirement?
> This is exactly what the latest-compatible-conflict-manager introduced
> recently do:
> https://issues.apache.org/jira/browse/IVY-648
>
> This is available in trunk and will be too in 2.0.0 beta 1 which is
> just
> around the corner.
>
> Xavier
>
> >
> >
> >
> > Thanks,
> > Mayer
RE: Question about revision conflicts during resolve/retrieve
Posted by "Crystal, Mayer" <ma...@gs.com>.
This wouldn't by chance be backward compatible with 1.4, would it? :)
-----Original Message-----
From: Xavier Hanin [mailto:Xavier.Hanin@sas.com]
Sent: Thursday, December 06, 2007 10:51 AM
To: ivy-user@incubator.apache.org
Subject: RE: Question about revision conflicts during resolve/retrieve
> -----Original Message-----
> From: Crystal, Mayer [mailto:mayer.crystal@gs.com]
> Sent: Thursday, December 06, 2007 10:47 AM
> To: ivy-user@incubator.apache.org
> Cc: Etkine, Dmitri
> Subject: Question about revision conflicts during resolve/retrieve
>
> We are using Ivy 1.4.1 and had a question about conflict resolution
> between 2 modules. Let's say we have a setup like:
>
> A depends on B version 1.4 and C version 1.5 B depends on C version
> 1.+ Version C in the repository is 1.7
>
>
> Is there a way to tell ivy that when it is resolving, if it comes
> across a firm requirement (1.5 for C for module A) which doesn't
> conflict with other requirements (the 1.+ for C for module B) to
> always choose the strict requirement?
This is exactly what the latest-compatible-conflict-manager introduced
recently do:
https://issues.apache.org/jira/browse/IVY-648
This is available in trunk and will be too in 2.0.0 beta 1 which is just
around the corner.
Xavier
>
>
>
> Thanks,
> Mayer
RE: Question about revision conflicts during resolve/retrieve
Posted by Xavier Hanin <Xa...@sas.com>.
> -----Original Message-----
> From: Crystal, Mayer [mailto:mayer.crystal@gs.com]
> Sent: Thursday, December 06, 2007 10:47 AM
> To: ivy-user@incubator.apache.org
> Cc: Etkine, Dmitri
> Subject: Question about revision conflicts during resolve/retrieve
>
> We are using Ivy 1.4.1 and had a question about conflict resolution
> between 2 modules. Let's say we have a setup like:
>
> A depends on B version 1.4 and C version 1.5
> B depends on C version 1.+
> Version C in the repository is 1.7
>
>
> Is there a way to tell ivy that when it is resolving, if it comes
> across
> a firm requirement (1.5 for C for module A) which doesn't conflict with
> other requirements (the 1.+ for C for module B) to always choose the
> strict requirement?
This is exactly what the latest-compatible-conflict-manager introduced recently do:
https://issues.apache.org/jira/browse/IVY-648
This is available in trunk and will be too in 2.0.0 beta 1 which is just around the corner.
Xavier
>
>
>
> Thanks,
> Mayer
Re: Question about revision conflicts during resolve/retrieve
Posted by Xavier Hanin <xa...@gmail.com>.
On Dec 13, 2007 8:02 PM, Niklas Matthies <ml...@nmhq.net> wrote:
> On Thu 2007-12-13 at 18:22h, Xavier Hanin wrote on ivy-user:
> > > > On Dec 10, 2007 1:02 PM, Niklas Matthies <ml...@nmhq.net>
> wrote:
> > > :
> > > > > I wonder whether an EarliestCompatibleConflictManager wouldn't
> > > > > be (even) more useful? It would have the property to yield
> > > > > reproducible results when newer versions are added to the
> > > > > repository.
> :
> > I'm suggesting to use the resolved ivy.xml to reproduce a build.
> > Putting it in source control is a good way to do so, but not the
> > only one. This article is worth reading:
> > http://dead-parrot.de/ivy/
>
> Thanks for that link. I actually read this some weeks ago, but had
> forgotten about that point.
>
> Let me try to motivate the suggested conflict manager a bit further,
> though. The approach outlined in the article above makes sense for the
> creation of patch releases. But we're actually at least as much
> concerned about stability of dependency resolution during development
> and testing, where builds happen on the trunk rather than being
> reproduced builds of frozen versions on a patch branch.
>
> That is, even during normal development and testing, we don't
> necessarily want builds to automatically get some latest revision of a
> dependee. This is true in particular for dependees that are not part
> of the project proper (e.g. libraries that are not specific to the
> project). In these cases we only want to get a later revision if and
> when the project in question actually requires it, and then we'll
> define the relevant dependency accordingly. This makes sure that
> during a build-test-fix-rebuild cycle, the rebuild doesn't introduce
> new bugs by getting a different revision of some dependee module than
> the previous build.
>
> Now, when specifying dependencies with fixed revisions in the Ivy
> files, you do get that kind of build stability using the default
> "latest-revision" conflict manager. If you have a diamond dependency
> where one path asks for revision 1.5 of a module and the other path
> asks for revision 1.6, then you'll get revision 1.6, and not some
> later revision that may have become available.
>
> The assumption behind that conflict manager, of course, is that later
> revisions usually do not break compatibility relative to earlier ones,
> thus getting revision 1.6 is okay even though one of the dependencies
> asked for revision 1.5. In other words, "1.5" is effectively treated
> as the version range "[1.5,)". Given that notion of compatibility, the
> "lastest-revision" conflict manager applied to fixed revisions is in
> fact an "earliest-compatible-revision" conflict manager!
>
> Specifying a version range with an upper bound, or a sub-revision
> pattern (i.e. with "+"), on the other hand, quite clearly says that a
> later revision should not be considered compatible any more. For
> example, "1.5" might be replaced by "[1.5,2.0[" if version 2.0 breaks
> compatibility. Then getting revision 1.6 would still be okay, but if
> the other path in the diamond dependency asks for some revision >=2.0,
> we want the dependency resolution to fail.
>
> This, of course(?), is what the new LatestCompatibleConflictManager
> will be doing. Only that with it we're losing the build stability the
> "latest-revision" conflict manager had given us with fixed revisions!
> If one path asks for "[1.5,2.0[" and the other asks for "[1.6,2.0[",
> we still want to get revision 1.6 as was previously the case, not
> revision 1.9 that might also be available.
>
> So, I hope I could clarify a bit why I think there ought to be an
> "earliest-compatible-revision" conflict manager.
I think I get the idea, now I better understand why you want such a feature.
But this would actually need more than just a conflict manager. Indeed, even
when you don't have a conflict, you want [1.5,2.0[ to be resolved to 1.5. So
this is beyond the scope of a conflict manager. Maybe it could be
implemented by a 'reversed' latest strategy, where you make Ivy think that
1.5 is more recent than 2.0, since Ivy always try to get the latest version,
and in your case you always want to take the earliest one.
Xavier
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: Question about revision conflicts during resolve/retrieve
Posted by Niklas Matthies <ml...@nmhq.net>.
On Thu 2007-12-13 at 18:22h, Xavier Hanin wrote on ivy-user:
> > > On Dec 10, 2007 1:02 PM, Niklas Matthies <ml...@nmhq.net> wrote:
> > :
> > > > I wonder whether an EarliestCompatibleConflictManager wouldn't
> > > > be (even) more useful? It would have the property to yield
> > > > reproducible results when newer versions are added to the
> > > > repository.
:
> I'm suggesting to use the resolved ivy.xml to reproduce a build.
> Putting it in source control is a good way to do so, but not the
> only one. This article is worth reading:
> http://dead-parrot.de/ivy/
Thanks for that link. I actually read this some weeks ago, but had
forgotten about that point.
Let me try to motivate the suggested conflict manager a bit further,
though. The approach outlined in the article above makes sense for the
creation of patch releases. But we're actually at least as much
concerned about stability of dependency resolution during development
and testing, where builds happen on the trunk rather than being
reproduced builds of frozen versions on a patch branch.
That is, even during normal development and testing, we don't
necessarily want builds to automatically get some latest revision of a
dependee. This is true in particular for dependees that are not part
of the project proper (e.g. libraries that are not specific to the
project). In these cases we only want to get a later revision if and
when the project in question actually requires it, and then we'll
define the relevant dependency accordingly. This makes sure that
during a build-test-fix-rebuild cycle, the rebuild doesn't introduce
new bugs by getting a different revision of some dependee module than
the previous build.
Now, when specifying dependencies with fixed revisions in the Ivy
files, you do get that kind of build stability using the default
"latest-revision" conflict manager. If you have a diamond dependency
where one path asks for revision 1.5 of a module and the other path
asks for revision 1.6, then you'll get revision 1.6, and not some
later revision that may have become available.
The assumption behind that conflict manager, of course, is that later
revisions usually do not break compatibility relative to earlier ones,
thus getting revision 1.6 is okay even though one of the dependencies
asked for revision 1.5. In other words, "1.5" is effectively treated
as the version range "[1.5,)". Given that notion of compatibility, the
"lastest-revision" conflict manager applied to fixed revisions is in
fact an "earliest-compatible-revision" conflict manager!
Specifying a version range with an upper bound, or a sub-revision
pattern (i.e. with "+"), on the other hand, quite clearly says that a
later revision should not be considered compatible any more. For
example, "1.5" might be replaced by "[1.5,2.0[" if version 2.0 breaks
compatibility. Then getting revision 1.6 would still be okay, but if
the other path in the diamond dependency asks for some revision >=2.0,
we want the dependency resolution to fail.
This, of course(?), is what the new LatestCompatibleConflictManager
will be doing. Only that with it we're losing the build stability the
"latest-revision" conflict manager had given us with fixed revisions!
If one path asks for "[1.5,2.0[" and the other asks for "[1.6,2.0[",
we still want to get revision 1.6 as was previously the case, not
revision 1.9 that might also be available.
So, I hope I could clarify a bit why I think there ought to be an
"earliest-compatible-revision" conflict manager.
-- Niklas Matthies
Re: Question about revision conflicts during resolve/retrieve
Posted by Xavier Hanin <xa...@gmail.com>.
On Dec 11, 2007 6:58 PM, Niklas Matthies <ml...@nmhq.net> wrote:
> On Tue 2007-12-11 at 18:41h, Xavier Hanin wrote on ivy-user:
> > On Dec 10, 2007 1:02 PM, Niklas Matthies <ml...@nmhq.net> wrote:
> :
> > > I wonder whether an EarliestCompatibleConflictManager wouldn't be
> > > (even) more useful? It would have the property to yield reproducible
> > > results when newer versions are added to the repository.
> >
> > For build reproducibility we rather recommend to fix revisions when
> > publishing your module,
>
> Ok, I think I'm missing something. Are you suggesting to put a
> resolved ivy.xml into source control (along with the regular,
> unresolved, evolving ivy.xml) which then should be used to reproduce
> builds of the module?
I'm suggesting to use the resolved ivy.xml to reproduce a build. Putting it
in source control is a good way to do so, but not the only one. This article
is worth reading:
http://dead-parrot.de/ivy/
Xavier
>
>
> > but it would be interesting (at least people not
> > following this recommendation), so feel free to open an issue.
>
> Will do so.
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: Question about revision conflicts during resolve/retrieve
Posted by Niklas Matthies <ml...@nmhq.net>.
On Tue 2007-12-11 at 18:41h, Xavier Hanin wrote on ivy-user:
> On Dec 10, 2007 1:02 PM, Niklas Matthies <ml...@nmhq.net> wrote:
:
> > I wonder whether an EarliestCompatibleConflictManager wouldn't be
> > (even) more useful? It would have the property to yield reproducible
> > results when newer versions are added to the repository.
>
> For build reproducibility we rather recommend to fix revisions when
> publishing your module,
Ok, I think I'm missing something. Are you suggesting to put a
resolved ivy.xml into source control (along with the regular,
unresolved, evolving ivy.xml) which then should be used to reproduce
builds of the module?
> but it would be interesting (at least people not
> following this recommendation), so feel free to open an issue.
Will do so.
-- Niklas Matthies
Re: Question about revision conflicts during resolve/retrieve
Posted by Xavier Hanin <xa...@gmail.com>.
On Dec 11, 2007 7:15 PM, Crystal, Mayer <ma...@gs.com> wrote:
> Does the new(er) version of ivy now support a publish which will replace
> all non-specific versions in the module file with specific versions
> (i.e. 1.+ -> 1.3.2 when it is published)?
Besides some bugs which should be fixed in latest Ivy version, Ivy supports
that since day 1.
Xavier
>
>
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Tuesday, December 11, 2007 12:42 PM
> To: ivy-user@incubator.apache.org
> Subject: Re: Question about revision conflicts during resolve/retrieve
>
> On Dec 10, 2007 1:02 PM, Niklas Matthies <ml...@nmhq.net> wrote:
>
> > On Thu 2007-12-06 at 10:49h, Jim Adams wrote on ivy-user:
> > > We call this the "Polygon of Death". There will be a conflict
> > > manager in the beta called LatestCompatibleConflictManager which
> > > will handle this case.
> >
> > I wonder whether an EarliestCompatibleConflictManager wouldn't be
> > (even) more useful? It would have the property to yield reproducible
> > results when newer versions are added to the repository.
>
> For build reproducibility we rather recommend to fix revisions when
> publishing your module, but it would be interesting (at least people not
> following this recommendation), so feel free to open an issue.
>
> Xavier
>
> >
> >
> > -- Niklas Matthies
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/
> http://ant.apache.org/ivy/ http://www.xoocode.org/
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: Question about revision conflicts during resolve/retrieve
Posted by "Crystal, Mayer" <ma...@gs.com>.
Does the new(er) version of ivy now support a publish which will replace
all non-specific versions in the module file with specific versions
(i.e. 1.+ -> 1.3.2 when it is published)?
-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
Sent: Tuesday, December 11, 2007 12:42 PM
To: ivy-user@incubator.apache.org
Subject: Re: Question about revision conflicts during resolve/retrieve
On Dec 10, 2007 1:02 PM, Niklas Matthies <ml...@nmhq.net> wrote:
> On Thu 2007-12-06 at 10:49h, Jim Adams wrote on ivy-user:
> > We call this the "Polygon of Death". There will be a conflict
> > manager in the beta called LatestCompatibleConflictManager which
> > will handle this case.
>
> I wonder whether an EarliestCompatibleConflictManager wouldn't be
> (even) more useful? It would have the property to yield reproducible
> results when newer versions are added to the repository.
For build reproducibility we rather recommend to fix revisions when
publishing your module, but it would be interesting (at least people not
following this recommendation), so feel free to open an issue.
Xavier
>
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/
http://ant.apache.org/ivy/ http://www.xoocode.org/
Re: Question about revision conflicts during resolve/retrieve
Posted by Xavier Hanin <xa...@gmail.com>.
On Dec 10, 2007 1:02 PM, Niklas Matthies <ml...@nmhq.net> wrote:
> On Thu 2007-12-06 at 10:49h, Jim Adams wrote on ivy-user:
> > We call this the "Polygon of Death". There will be a conflict
> > manager in the beta called LatestCompatibleConflictManager which
> > will handle this case.
>
> I wonder whether an EarliestCompatibleConflictManager wouldn't be
> (even) more useful? It would have the property to yield reproducible
> results when newer versions are added to the repository.
For build reproducibility we rather recommend to fix revisions when
publishing your module, but it would be interesting (at least people not
following this recommendation), so feel free to open an issue.
Xavier
>
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: Question about revision conflicts during resolve/retrieve
Posted by Niklas Matthies <ml...@nmhq.net>.
On Thu 2007-12-06 at 10:49h, Jim Adams wrote on ivy-user:
> We call this the "Polygon of Death". There will be a conflict
> manager in the beta called LatestCompatibleConflictManager which
> will handle this case.
I wonder whether an EarliestCompatibleConflictManager wouldn't be
(even) more useful? It would have the property to yield reproducible
results when newer versions are added to the repository.
-- Niklas Matthies
RE: Question about revision conflicts during resolve/retrieve
Posted by Jim Adams <Ji...@sas.com>.
We call this the "Polygon of Death". There will be a conflict manager in the beta called LatestCompatibleConflictManager which will handle this case.
Jim Adams
> -----Original Message-----
> From: Crystal, Mayer [mailto:mayer.crystal@gs.com]
> Sent: Thursday, December 06, 2007 10:47 AM
> To: ivy-user@incubator.apache.org
> Cc: Etkine, Dmitri
> Subject: Question about revision conflicts during resolve/retrieve
>
> We are using Ivy 1.4.1 and had a question about conflict resolution
> between 2 modules. Let's say we have a setup like:
>
> A depends on B version 1.4 and C version 1.5
> B depends on C version 1.+
> Version C in the repository is 1.7
>
>
> Is there a way to tell ivy that when it is resolving, if it comes across
> a firm requirement (1.5 for C for module A) which doesn't conflict with
> other requirements (the 1.+ for C for module B) to always choose the
> strict requirement?
>
>
>
> Thanks,
> Mayer