Status constraints on dependencies

[Niklas Matthies <ml...@nmhq.net>]

Will the new revision constraints feature allow to specify status
constraints?

More specifically, consider the following example.
Given the following dependencies:

   #A -> { #B;1.7.1 #C;2.1 }
   #C;2.1 -> #B;1.7.2

And in the repository:

   #B;1.7.1 status=stable
   #B;1.7.2 status=unstable
   #B;1.7.3 status=stable
   #B;1.7.4 status=stable

Resolving A's dependencies will result in revision 1.7.2 of B to be
selected. Note that this is an unstable release although A's direct
dependency was on a stable release.

So I'd like to specify a status constraint on the A->B dependency,
i.e. (imaginary syntax):

   #A -> #B;1.7.1;status=stable

And the desired effect would be that revision 1.7.3 (NOT 1.7.4) of B
is selected, in other words the least upper bound of the revisions
resulting from the dependencies that matches the status constraint.

Put slightly differently, it should behave as if the repository only
contained the stable revisions of B. Think of it as a filter applied
to Ivy's view of the repository.

(And if there wasn't any release above 1.7.2 with status stable or
better, dependency resolution should fail due to an unresolvable
conflict.)

If the revision constraints feature supports status constraints, will
it work that way? If not, shouldn't it?

Or what other possible venues are there be to achieve this behavior?

-- Niklas Matthies

Re: Status constraints on dependencies

[Xavier Hanin <xa...@gmail.com>]

On Wed, Jun 18, 2008 at 6:15 PM, Niklas Matthies <ml...@nmhq.net>
wrote:

> Will the new revision constraints feature allow to specify status
> constraints?
>
> More specifically, consider the following example.
> Given the following dependencies:
>
>   #A -> { #B;1.7.1 #C;2.1 }
>   #C;2.1 -> #B;1.7.2
>
> And in the repository:
>
>   #B;1.7.1 status=stable
>   #B;1.7.2 status=unstable
>   #B;1.7.3 status=stable
>   #B;1.7.4 status=stable
>
> Resolving A's dependencies will result in revision 1.7.2 of B to be
> selected. Note that this is an unstable release although A's direct
> dependency was on a stable release.
>
> So I'd like to specify a status constraint on the A->B dependency,
> i.e. (imaginary syntax):
>
>   #A -> #B;1.7.1;status=stable
>
> And the desired effect would be that revision 1.7.3 (NOT 1.7.4) of B
> is selected, in other words the least upper bound of the revisions
> resulting from the dependencies that matches the status constraint.
>
> Put slightly differently, it should behave as if the repository only
> contained the stable revisions of B. Think of it as a filter applied
> to Ivy's view of the repository.
>
> (And if there wasn't any release above 1.7.2 with status stable or
> better, dependency resolution should fail due to an unresolvable
> conflict.)
>
> If the revision constraints feature supports status constraints, will
> it work that way? If not, shouldn't it?
>
> Or what other possible venues are there be to achieve this behavior?

This behavior should be possible with a custom conflict manager, and a
custom dependency resolver or dependency mediator. This is not very easy to
implement, especially because a conflict manager can't select a revision
which is not in the conflict. But this is feasible with plugins only. An
alternate way is to patch Ivy and share the patch with the community.

Xavier


>
>
> -- Niklas Matthies
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/