ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Zethelius <>
Subject RE: Ivy not resolving transitive dependencies
Date Wed, 09 May 2012 03:12:56 GMT
RE: Transitivity, make sure you set the <ivy pattern ...> in the resolver.  Without it,
it won't find the published ivy files, only the raw artifacts so it won't know the relationship.

From: Troy Kinsella []
Sent: Tuesday, May 08, 2012 6:45 PM
Subject: Ivy not resolving transitive dependencies


I'm new to Ivy and I think I'm fumbling on what I think is a unique Ivy

- I have three modules: ModuleA depends on ModuleB depends on ModuleC.
- Resolving dependencies of ModuleB works correctly.
- I am building JavaScript modules where a module may depend on a
"source" artifact of another module (as opposed to a binary).
- I am trying to mimic Maven's SNAPSHOT version convention
- Artifacts are published to a company-internal "shared" Nexus repository
- I have been clearing the ivy cache continually as I change things
- I have read every Ivy documentation page about 10 times each :)

- I'm having trouble resolving transitive dependencies, and I'm unsure
where to start troubleshooting.
- Not sure if there is merit or benefit to mimicking Maven's SNAPSHOT
version convention. Is it getting in the way?
- I'm not sure if repository layout is an issue.
- I'm not sure if I'm using configurations correctly.
- I'd like to _not_ have to specify the exact artifact in my
dependencies, but it seems I need to to work with "source" artifacts.

- How do I solve the transitive dependency resolution issue?
- Is there a better way to configure Ivy to achieve the equivalent
- Does Ivy have special handling of certain artifact types, such as the
default (binary, I guess), "sources", or "javadoc"?
- Are there any best practices that I am blatantly violating?

Relevant configuration files:

===== ivysettings.xml =====

<settings defaultResolver="default"/>
<include url="ivysettings-public.xml"/> <!-- currently unused -->
<include url="ivysettings-shared.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-local.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/>

===== ivysettings-shared.xml =====

<url name="shared" m2compatible="true">

===== ModuleC ivy.xml =====

<info organisation=""
           revision="1.0-SNAPSHOT" />

<conf name="doc" />
<conf name="source" />
<conf name="runtime" />

<artifact name="ModuleC-source" type="source" ext="jar" conf="source" />
<artifact name="ModuleC-jsdoc" type="jsdoc" ext="zip" conf="doc" />

===== ModuleB ivy.xml =====

<info organisation=""
           revision="1.0-SNAPSHOT" />

<conf name="doc" />
<conf name="source" />
<conf name="runtime" />

<artifact type="jar" />
<artifact name="ModuleB-source" type="source" ext="jar" conf="source" />

<dependency org="" name="ModuleC" rev="1.0-SNAPSHOT">
<artifact name="ModuleC-source" conf="source" />

===== ModuleA ivy.xml =====

<info organisation=""
           revision="1.0-SNAPSHOT" />

<conf name="doc" />
<conf name="source" />
<conf name="runtime" />

<artifact name="ModuleA" type="jar" conf="runtime" />

<dependency org="" name="ModuleB" rev="1.0-SNAPSHOT">
<artifact name="ModuleB-source" conf="source" />

<!-- I have to have this to resolve this transitive dependency... why? -->
<!-- <dependency org="" name="ModuleC" rev="1.0-SNAPSHOT">
<artifact name="ModuleC-source" conf="source" />
</dependency> -->


When I publish ModuleC, it results in the following files:

[ivy:publish]     published ModuleC-jsdoc to
[ivy:publish]     published ModuleC-source to
[ivy:publish]     published ivy to

When I publish ModuleB, it results in the following files:

[ivy:publish]     published ModuleB to
[ivy:publish]     published ModuleB-source to
[ivy:publish]     published ivy to

I am resolving dependencies in ant like so:

<ivy:resolve />
<ivy:retrieve pattern="lib/[artifact].[ext]" />

After trying to build ModuleA, I only have the following under ModuleA/lib:


I also need ModuleC-source.jar in order to build ModuleA.


Troy Kinsella
View raw message