ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: install task from Maven repo misses TRANSITIVE source artifacts
Date Wed, 02 Dec 2009 18:48:17 GMT
Well, this is one of those moments when I just want to slap myself on the
forehead. It should have been obvious why Ivy wasn't getting source and
Javadoc for transitive dependencies. Because source and Javadoc get their
own Ivy confs in the generated ivy.xml, and those corresponding confs
weren't being specified on the dependencies.

Here's just one dependency from the ivy.xml that gets generated for the root
pom.xml:
<dependency org="org.apache.commons" name="commons-cli" rev="1.2"
            force="true"
            conf="compile->compile(*),master(*);runtime->runtime(*)">

To get the source and Javadoc, the conf attribute's value really should be
something like:
"compile->compile(*),master(*);runtime->runtime(*);sources->sources;javadoc->javadoc
"

So really, the more precise question is, for the ivy.xml that Ivy generates
from a POM, why isn't it applying the "sources" and "javadoc" confs to the
dependencies? Was there a decision involved? Is this something that could be
made configurable?

This may go back to some of the technical issues with Maven integration
raised in the "sources as conf or type" thread on this list, some of which I
didn't fully grasp at the time.

On Mon, Nov 30, 2009 at 4:15 PM, Mitch Gitman <mgitman@gmail.com> wrote:

> 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:
> <publications>
>   <artifact name="commons-cli" type="jar" ext="jar" conf="master"/>
>   <artifact name="commons-cli" type="source" ext="jar" conf="sources"
> m:classifier="sources"/>
>   <artifact name="commons-cli" type="javadoc" ext="jar" conf="javadoc"
> m:classifier="javadoc"/>
> </publications>
>
> 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 <mgitman@gmail.com> 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 <mgitman@gmail.com> 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="
>>> http://repo1.maven.org/maven2" />
>>>
>>> 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?
>>>
>>
>>
>

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