On Wed, Feb 27, 2008 at 8:05 PM, Niklas Matthies <[EMAIL PROTECTED]>
wrote:
> On Wed 2008-02-27 at 18:56h, Xavier Hanin wrote on ivy-user:
> :
> > Mm, we currently use dependencies/dependency only for direct
> > dependencies. And this is not a direct dependency. So I'd really
> > prefer to keep it separated, as the conflicts section.
>
> Scott Oster hits the nail on the head when he says that it's actually
> a revision constraint. It occurs to me that it might generally be
> helpful to distinguish between dependencies ("module A requires
> module B, period") and revision constraints ("module A only works with
> revisions x to y of module B (not necessarily implying that A requires
> B)").
>
> You might remember our discussion where I wanted (for the purpose of
> build reproducability) the earliest, rather than the latest, revision
> to be retrieved that matches specific version constraints. The problem
> there was as well that a corresponding conflict manager would only
> kick in when there's an actual conflict. Maybe what we really need is
> a "revision selector" which selects one or more revisions from the set
> of revisions that is the intersection between the set of revisions
> available in the repository and the set defined by the revision
> constraints. (This has aspects from both latest-strategy and conflict
> managers.) An actual conflict manager would only kick in when the set
> defined by the version constraints becomes empty, i.e. when there is a
> conflict between the *constraints* imposed by (different) dependent
> modules.
This sounds interesting. This requires more thinking, to see what could
really be achieved with that. I guess you already have a pretty good idea,
I'm looking forward to have more details about what you envision and the
associated use cases.
Xavier
>
>
> I need to think a bit about how this could be made efficient in terms
> of minimizing ivy file retrievals. (I'm pretty certain it can.)
>
> -- Niklas Matthies
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
