ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Problem with revConstraint
Date Mon, 04 Aug 2008 17:57:34 GMT
On Wed, Jul 30, 2008 at 3:34 PM, Foreman, Alex (IT) <> wrote:

> Hi,
> We use a custom version matcher that loads in default values from a
> property file and when rev="default" we look for a property called
> 'org.module.default' and use that value.
> E.g.
> Apache.ivy.default=1.3
> Would match org="apache" name="ivy" rev="default" to rev="1.3" in the
> delivered ivy file and also place revConstraint="default" into that
> dependency.
> If we have someone that consumes this ivy that does not load up the
> properties file we fail even tho we are using resolveMode="default".  IE it
> shuld not take into account the revConstraint.  It is however trying to work
> this out anyway and causing the cachepath to fail as our default version
> matcher cannot find the property.
> Eg I ask for Apache#ivy!1.3
> The ivy file has a revConstraint="default" in its dependeny and we crash
> out even tho I specifed an exact value and did not want to use the default.
> My question is:
> Why does the resolve/cachepath look at the revConstraint  when we are not
> interested in it in resolveMode="true".

In default resolveMode, the revConstraint should be ignored except for
reporting. After checking the code it seems that there's one place where
it's used whatever the setting is: in ModuleInSort class. I see no reason
why this is used, I guess it's due to the initial way of dealing with
resolveMode, but now we use a mediation mechanism, so now using the
dependency revision id seems to be better. I've just committed this change
in Ivy, could you try out the trunk version and tell if it works better.


> Can we :
> a) not try to resolve the revConstraint if it is not needed?
> B) strip revConstraint out on a deliver so its not there?
> C) tell ivy to always ignore the revConstraint.
> Can we currently do any of the above 3?
> If not do people consider this a bug and should it be fixed?
> Many thanks,
> Alex Foreman
> Morgan Stanley | Technology
> 20 Cabot Square | Canary Wharf | Floor 06
> London, E14 4QW
> Phone: +44 20 7677-5732
> --------------------------------------------------------
> NOTICE: If received in error, please destroy and notify sender. Sender does
> not intend to waive confidentiality or privilege. Use of this email is
> prohibited when received in error.

Xavier Hanin - Independent Java Consultant

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