While on this subject, is there a way to centrally manage the list of configurations available in an ivy file? Personally I would have created a default set of configurations in the settings file and then allowed the ivy files to modify the defaults.
> -----Original Message----- > From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED] > Sent: Monday, March 24, 2008 3:08 PM > To: [email protected] > Subject: RE: specify versions separate from dependencies > > To elaborate on Jim's point, it is important to consider mechanisms that > allow for centralized management of > this new feature. > > I can see how this feature would be used to override the dependency of > commonly used jars. For companies with > hundreds of projects using those jars, having a single place to manage > overrides would be immensely valuable. > > Having a similar session on the ivy settings files (that you could customize > with variables) providing default > values that the ivy-module could refine would be a way. > > /Nascif > > > -----Original Message----- > From: Jim Adams [mailto:[EMAIL PROTECTED] > Sent: Monday, March 24, 2008 2:48 PM > To: [email protected] > Subject: RE: specify versions separate from dependencies > > 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:[EMAIL PROTECTED] > > Sent: Monday, March 24, 2008 2:31 PM > > To: [email protected] > > 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 <[EMAIL PROTECTED]> wrote: > > > > > On Wed, 27 Feb 2008 14:23:50 +0100 > > > "Xavier Hanin" <[EMAIL PROTECTED]> 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/
