On 3/29/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
And what if you depend (directly or indirectly) on 2 different versions of the same module in two different confs?
It depends if these two configurations fall into one root module conf or not. If they are in two separate root module conf (by root I mean the module for which the dependency resolution is being done), then no problem, there is no conflict, and you will get one version in one conf and another version in the other conf. If your two confs fall into one root module conf, there is a conflict in this root module conf, and depending on your conflict manager settings, Ivy will merge the required confs of the evicted module to the selected one. - Xavier Gilles
> -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: mercredi 28 mars 2007 21:57 > To: [email protected] > Subject: Re: IvyPostResolve Task question > > On 3/28/07, Maarten Coene <[EMAIL PROTECTED]> wrote: > > > > ok, I'll create a JIRA issue to make it possible to specify the Ivy > file. > > > > Another question about this task. > > It seems that this task also performs a resolve when not all necessary > > configurations were resolved in a previous resolve. > > > > I think this was added intentionally, but this behaviour isn't > documented > > so I'm not sure. > > But will this additional resolve always be correct? Is it possible that > > the resolve of a single configuration has a different result than a > resolve > > of the same configuration together with other configurations? For > instance: > > some modules could get convicted in the second situation (resolving > multiple > > configs) where they won't get convicted in the first situation (single > > config). > > > I'm not sure of what you mean by convicted (evicted maybe?) but > configurations are independent, and if the resolution of several confs at > a > time lead to a different result than confs one by one, it's a bug. The > only > difference between resolving confs one by one or all together is > performance. That's why post resolve tasks can safely resolve only missing > configurations if any. > > - Xavier > > regards, > > Maarten > > > > > > > > ----- Original Message ---- > > From: Xavier Hanin <[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Wednesday, March 28, 2007 10:09:53 AM > > Subject: Re: IvyPostResolve Task question > > > > On 3/28/07, Maarten Coene <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > I've taken a look at the IvyPostResolve task, and I have a question > > about > > > when this tasks performs a resolve. > > > According to the documentation, this happens for instance when no > > previous > > > resolve was performed. > > > > > > I was wondering which Ivy file will (or should) be resolved in this > > > situation because it doesn't seem possible to define a file attribute > on > > > these tasks. > > > > > > Yes, the file used is ${ivy.dep.file}, i.e. ivy.xml if it hasn't been > > defined in the ant build. Adding the option to set this file in all post > > resolve tasks would be pretty easy and convenient I think... > > > > - Xavier > > > > regards, > > > Maarten > > > > > > > > > > > > > > > > > > > > > > > > __________________________________________________________________________ > __________ > > > It's here! Your new message! > > > Get new email alerts with the free Yahoo! Toolbar. > > > http://tools.search.yahoo.com/toolbar/features/mail/ > > > > > > > > > > > > > > > > > > > > __________________________________________________________________________ > __________ > > No need to miss a message. Get email on-the-go > > with Yahoo! Mail for Mobile. Get started. > > http://mobile.yahoo.com/mail > >
