Over a million developers have joined DZone.

Ivy resolves downloads but ignores some artifacts (though not modules)

· Java Zone

Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code! Brought to you in partnership with ZeroTurnaround.

I’ve had a strange issue with Apache Ivy‘s resolve task – it resolved and downloaded all my dependencies but didn’t put some of them to the classpath (via ivy:cachepath) and certainly wouldn’t copy them either (via ivy:retrieve). An indicia was that in the resolve report the number of “artifacts” was zero while the number of “modules” matched the number of the dependencies. The issue was caused by my defaultconfmapping=”*->compile” – it turned out that most modules, as interpreted by Ivy, produce their artifacts only for the configuration “master” and not for compile.

In my case, with ivy.xml (definition of the configurations compile, provided, and test not shown) containing

<dependencies defaultconf="compile">
<dependency conf="provided" org="log4j" name="log4j" rev="1.2.14" />
<dependency conf="test" org="net.jakubholy.testing" name="dbunit-embeddedderby-parenttest" rev="1.1.0" />
<dependency conf="test" org="org.mockito" name="mockito-all" rev="1.8.5" />

the test-scoped dependencies net.jakubholy.testing:dbunit-embeddedderby-parenttest:1.1.0 and org.mockito:mockito-all:1.8.5 were included in the classpath together with their dependencies as expected while log4j:log4j:1.2.14 was ignored no matter what I did (even changing its conf to test).

The problem was indicated by <ivy:resolve /> producing an output like:

[ivy:resolve] :: resolution report :: resolve 951ms :: artifacts dl 20ms
| | modules || artifacts |
| conf | number| search|dwnlded|evicted|| number|dwnlded|
| compile | 0 | 0 | 0 | 0 || 0 | 0 |
| test | 13 | 0 | 0 | 1 || 10 | 0 |
| provided | 1 | 0 | 0 | 0 || 0 | 0 |
| runtime | 0 | 0 | 0 | 0 || 0 | 0 |


Checking the resolve report in <user home>/.ivy2/cache/resolved-<org>-<artifact>-<revision>.xml revealed the full definition of configurations (included from another file), dependencies and especially dependencies/defaultconfmapping, which was rather useful later. The defaultconfmapping

<dependencies defaultconf="compile" defaultconfmapping="*->compile">

seemed to be OK but was not, as further exploration revealed.

Next I’ve checked the Ivy descriptor for the log4j “module” generated by Ivy from its pom.xml in .ivy2/cache/log4j/log4j/ivy-1.2.14.xml and its publications tag caught my eye:

<artifact name="log4j" type="jar" ext="jar" conf="master"/>
<artifact name="log4j" type="source" ext="jar" conf="sources" m:classifier="sources"/>

- notice that the JAR artifact (i.e. log4j.jar) is produced only for the configuration ‘master’! But due to the innocently looking default mapping of “*->compile” we are taking into account only artifacts produced in the configuration “compile”, which is zero. Mystery solved!


The fix (not necessarily the best one) is to include all configurations of interest in the default mapping (either on dependencies or on configurations in ivy.xml):

<dependencies defaultconf="compile" defaultconfmapping="*->compile,master,default">


From http://theholyjava.wordpress.com/2010/12/23/ivy-resolve-downloads-but-ignores-some-artifacts-though-not-modules/

The Java Zone is brought to you in partnership with ZeroTurnaround. Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code!


Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}