ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject Re: specify versions separate from dependencies
Date Fri, 28 Mar 2008 08:03:45 GMT
I like the hints syntax under dependencies.  (Even I'm not sure hints
is the right word).

I agree with Jim.  We must have the possibility to centraly manage
your 'hints'.  Typically in a multi-module product, the 'hints' will
be a global charachteristic of the product, and only occasionaly
something specific to a module.

So, I think that allowing to include a file like we can include a file
for the configurations would be a good solution.  Like Xavier, I'm not
in favor of adding this to the settings.

However, when published, the included files must be in-lined so that
the published files are self-containing.

Finally, I'm currious to see how the new feature will impact the build
traces and the dependency report.

Gilles


On 24/03/2008, Jim Adams <Jim.Adams@sas.com> wrote:
> Is there any way to include this from another file? What I am thinking of is that we
have a properties file filled with the default versions of third party dependencies that our
build wants to use. We have different build tracks, corresponding to different installable
portions of our system, where people may decide that they want to override the original third
party dependencies. It seems that this would be possible with this system. I am concerned
that I will end up with conflicts, however, and not know it nor really understand the implications
of these conflicts.
>
>
>  > -----Original Message-----
>  > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
>
> > Sent: Monday, March 24, 2008 2:31 PM
>  > To: ivy-user@ant.apache.org
>  > Subject: Re: specify versions separate from dependencies
>  >
>
> > 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/
>


-- 
Gilles Scokart

Mime
View raw message