ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: specify versions separate from dependencies
Date Wed, 26 Mar 2008 15:54:58 GMT
I forward this message to dev list, since I would really like to get some
feedback from Ivy committers on the syntax to use for this feature.

On Mon, Mar 24, 2008 at 7:30 PM, Xavier Hanin <xavier.hanin@gmail.com>
wrote:

> I've started working on this, and come close to a solution. To finalize my
> work, we need to decide upon the syntax we want to use in Ivy files to
> support transitive dependency override mechanism.
>
> After some more thoughts on the feature and how it relates to existing Ivy
> features, I think we now have 3 different ways to influence transitive
> dependencies in an Ivy file:
> - transitive dependency exclusion (IVY-431), introduced in 2.0.0-alpha1.
> This feature relies on an 'exclude' tag directly under the 'dependencies'
> element.
> - setting specific conflict managers for transitive dependencies. This
> relies on a 'conflicts' element and its child elements 'manager'.
> - overriding version and/or branch of transitive dependencies. In the
> implementation, I've opened the door to more feature than that, by
> implementing a dependency descriptor mediator mechanism. Whenever we load a
> module descriptor dependency descriptors to resolve them, we first ask all
> the dependers to mediate each dependency descriptor. Then we use the
> mediated dependency descriptor to resolve the dependency, instead of the
> original one. For the moment I've only implemented one mediator, called
> override. But we could later imagine other kinds of mediation which happens
> before actual dependency resolution. For the moment I've used this syntax
> for this new feature:
>     <engine-hints>
>         <mediation>
>             <override org="yourorg" module=".*1" matcher="regexp"
> branch="BRANCH" rev="1.0" />
>         </mediation>
>     </engine-hints>
> This section is put directly under ivy-module element. What I would like
> to do is group the three kind of transitive dependencies hints we can give
> to the resolve engine in an ivy file. I'm still wondering what is the best
> syntax, and if we can afford deprecating the syntax of conflicts and module
> wide exclude. If we agree to deprecate them, here's one idea for the new
> syntax:
> <ivy-module>
>   <dependencies>
>     <dependency ... />
>     <dependency ... />
>     ...
>     <hints>
>       <exclude org="" module="" matcher="" ... />
>       <conflict org="" module="" matcher="" rev|manager="" />
>       <override org="" module="" matcher="" branch="" rev="" />
>     </hints>
>   </dependencies>
> </ivy-module>
> The conflict tag is similar to the current conflicts/manager tag, except
> that the 'name' attribute is replaced by 'manager'.
> All three kind of hints share the same attribute triple (org - module -
> matcher). The usage of this uple is slightly different in exclude, where it
> also applied to other attributes, such as artifact (to name the artifacts to
> exclude transitively).
>
> Another approach would be to put the hints section directly under
> ivy-module instead of under dependencies (as it's the case for
> conflicts/manager today). I think I prefer the former approach I propose.
>
> This is open to discussion, please give your feedback, once 2.0 will be
> out we won't be able to go back.
>
> Xavier
>
>
> On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann <harry@unheit.net> wrote:
>
> > On Wed, 27 Feb 2008 14:23:50 +0100
> > "Xavier Hanin" <xavier.hanin@gmail.com> wrote:
> >
> > > Could you open an issue about that?
> >
> > Here it is: https://issues.apache.org/jira/browse/IVY-753
> >
> > harry
> >
>
>
>
> --
> 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/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message