ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Conflicting module configurations
Date Wed, 19 Dec 2007 16:25:10 GMT
On Dec 19, 2007 12:30 AM, John Hungerford <>

> I'm new to ivy and mailing lists, so I apologize if this message is a
> duplicate.  When I upgraded from ivy 2.0.0-alpha2 to 2.0.0-beta1, the
> ivy:resolve task in my build file started failing while trying to
> resolve several dependencies that worked in alpha 2.  After narrowing
> down the problem, I've determined that ivy only honors the first set of
> configurations it sees when it resolves multiple versions of a module.
> For example, say I'm developing the foo module which depends on
> commons-beanutils 1.6 and commons-beanutils 1.7.0.  (In real life foo
> would only depend on 1.7.0 - this example represents the case where our
> module depends on multiple version of an artifact due to transitive
> dependencies, which is a very common occurrence in our enterprise
> repository.)

Ivy doesn't actually support depending on the same module twice, even though
we have never made this appear as an error. Having two versions of a module
requested through transitive dependencies is handled differently in Ivy, so
I'd recommend trying to reproduce the problem whilst still using transitive
dependencies. For instance #A;1.0->{#B;1.0 #commons-beanutils;1.6} and

> Here's the ivy.xml file for foo:
> <ivy-module version="1.3">
>        <info organisation="acme" module="foo" revision="1.0" />
>        <configurations>
>                <conf name="default" extends="master,runtime" />
>                <conf name="master" description="This module's artifact"
> />
>                <conf name="runtime" description="Mandatory runtime
> dependencies" />
>        </configurations>
>        <publications>
>                <artifact name="foo" type="jar" conf="master" />
>        </publications>
>        <dependencies defaultconfmapping="*->default">
>                <dependency org="apache" name="commons-beanutils"
> rev="1.6" conf="runtime" />
>                <dependency org="apache" name="commons-beanutils"
> rev="1.7.0" conf="runtime" />
>        </dependencies>
> </ivy-module>
> Commons-beanutils 1.6 declares three configurations:
> <ivy-module version="1.3">
>        <info organisation="apache" module="commons-beanutils"
> revision="1.6" status="integration"/>
>        <configurations>
>                <conf name="default" extends="runtime,master"/>
>                <conf name="master" />
>                <conf name="runtime" />
>        </configurations>
>        <publications>
>                <artifact name="commons-beanutils" type="jar"
> conf="master"/>
>        </publications>
> </ivy-module>
> Finally, commons-beanutils 1.7.0 only declares the default
> configuration:
> <ivy-module version="1.3">
>        <info organisation="apache" module="commons-beanutils"
> revision="1.7.0" status="release" />
>        <configurations>
>                <conf name="default" />
>        </configurations>
>        <publications>
>                <artifact name="commons-beanutils" type="jar"
> conf="default" />
>        </publications>
> </ivy-module>
> When I try to resolve the dependencies for foo, ivy tries to resolve the
> master and runtime configurations for commons-beanutils 1.7.0.  When I
> swap the order of the dependencies in foo's ivy.xml file, ivy only tries
> to resolve the default configuration of commons-beanutils 1.6.  This
> didn't occur in alpha2.  Is ivy behaving as expected?  I think it should
> resolve the default, master, and runtime configurations in
> commons-beanutils 1.6 and the default configuration in 1.7.0.  I can
> post ant's verbose output if it would help.

This is a problem of conflict resolution, and really depend on how you
configure your conflict management, and the order of the dependencies. If
Ivy find 1.6 before 1.7, it will try to resolve the default conf (since you
ask for it when you say runtime with defaultconfmapping=*->default), which
in turn extends master and runtime conf in beanutils 1.6. Later it will find
1.7, select it and evict 1.6 (if your conflict manager says so), and merge
information from the 1.6 revision to the 1.7. The information merged is the
callers (ie dependers) the required confs (in your case default in both
cases), the root module configuration in which the module is needed, the
dependency artifacts declared by dependers if any (none in your case) and
the current state of which configurations have been loaded. So even though
Ivy has loaded the runtime and master conf for 1.6, the selection of
1.7will just consider the dependencies of
1.7 in its default conf.

If Ivy finds 1.7 before 1.6 it will evict 1.6 before actually resolving its
dependencies, which will save the time of resolving 1.6 dependencies, but
shouldn't alter the final result of dependencies.

So I don't know if this is actually what you encounter in your use case, I'm
not sure to get exactly what's going wrong for you. If you think Ivy doesn't
behave like I've explained, give some more details (including verbose log),
but before try to use transitive dependencies instead of declaring the same
dependency twice.



> Keep up all the great work!
> John Hungerford
> Co-op Developer
> Air2Web

Xavier Hanin - Independent Java Consultant

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