[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ivy-user
Subject:    Re: Question about revision conflicts during resolve/retrieve
From:       "Xavier Hanin" <xavier.hanin () gmail ! com>
Date:       2007-12-18 13:19:28
Message-ID: 635a05060712180519x2b4e0973u34a07fd081acf322 () mail ! gmail ! com
[Download RAW message or body]


On Dec 13, 2007 8:02 PM, Niklas Matthies <ml_ivy-user@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_ivy-user@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/


[prev in list] [next in list] [prev in thread] [next in thread]