ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: install task from Maven repo misses TRANSITIVE source artifacts
Date Tue, 01 Dec 2009 00:15:28 GMT
Here's a little further information I've been able to glean. If I look at
the ivy.xml files that have been generated in the dedicated Ivy cache for
the source Maven repository, I see that they are referring to the source and
javadoc artifacts--even though those artifacts are not there for the
transitive modules. For example:
  <artifact name="commons-cli" type="jar" ext="jar" conf="master"/>
  <artifact name="commons-cli" type="source" ext="jar" conf="sources"
  <artifact name="commons-cli" type="javadoc" ext="jar" conf="javadoc"

To me, what's odd is not so much that the source/javadoc artifact download
is NOT working for the dependencies. It's that it IS working for the
requested module. If something like this is failing, you'd expect it to fail
in all cases.

Anyway, if anyone has had any success in transitively retrieving source and
Javadoc doing an ivy:install from a Maven repo, I'd be curious to hear how
you accomplished it.

On Fri, Nov 27, 2009 at 10:31 PM, Mitch Gitman <> wrote:

> One other observation. I decided to associate the source ibiblio resolver
> with its own Ivy cache. When I examined the Ivy cache post-install, I found
> the same problem. The starting-point Ivy module had directories:
> * jars
> * javadocs
> * sources
> And these directories were populated correctly. But everything else just
> had:
> * jars
> I wouldn't be surprised if, upon doing an ivy:resolve directly against the
> Maven repository, the cache would experience the same information loss.
> On Fri, Nov 27, 2009 at 9:14 PM, Mitch Gitman <> wrote:
>> I've been trying to run ivy:install where the source repository is a Maven
>> repository.
>> I'm cognizant of the problem of binary, source, and Javodoc artifacts for
>> the same module overwriting each other unless you take special care to
>> distinguish them. So I made sure to incorporate a [type] entry in my
>> destination Ivy repository's artifact pattern:
>> <artifact
>> pattern="${...}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"
>> />
>> A funny thing happened when I did this. For the particular module on which
>> I ran ivy:install, it worked. For that generated Ivy module, jars, javadocs,
>> and sources directories appeared in the destination repository, with the
>> correct contents inside. But, for all that module's recursive transitive
>> dependencies, only a jars directory showed up. The source and Javadocs were
>> lost.
>> Reading through past mailing list threads, I saw a suggestion to use a
>> [classifier] entry, even though the documentation only refers to that in the
>> context of a packager resolver. So I tried the following artifact pattern:
>> <artifact
>> pattern="${...}/[organisation]/[module]/[revision]/[artifact](-[classifier]).[ext]"
>> />
>> And the result? Same problem. The source and javadoc artifacts show up for
>> the "root" module; they disappear for the rest.
>> For the record, my source Maven resolver is specified like so:
>> <ibiblio name="maven2.resolver" m2compatible="true" root="
>>" />
>> And I specify install like so:
>>       <ivy:install matcher="exact"
>>                    transitive="true"
>>                    overwrite="true"
>>                    organisation="..."
>>                    module="..."
>>                    revision="..."
>>                    from="..."
>>                    to="..." />
>> Anyone have success getting source and Javadoc artifacts to show up
>> transitively on an ivy:install from Maven?

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