Return-Path: 
 <ivy-user-return-6180-apmail-ant-ivy-user-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-ivy-user-archive@www.apache.org
Received: (qmail 11900 invoked from network); 1 Dec 2009 00:16:02 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 1 Dec 2009 00:16:02 -0000
Received: (qmail 77376 invoked by uid 500); 1 Dec 2009 00:16:01 -0000
Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org
Received: (qmail 77318 invoked by uid 500); 1 Dec 2009 00:16:00 -0000
Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:ivy-user-help@ant.apache.org>
List-Unsubscribe: <mailto:ivy-user-unsubscribe@ant.apache.org>
List-Post: <mailto:ivy-user@ant.apache.org>
List-Id: <ivy-user.ant.apache.org>
Reply-To: ivy-user@ant.apache.org
Delivered-To: mailing list ivy-user@ant.apache.org
Received: (qmail 77308 invoked by uid 99); 1 Dec 2009 00:16:00 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Dec 2009 00:16:00 +0000
X-ASF-Spam-Status: No, hits=2.2 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of mgitman@gmail.com designates
 209.85.222.181 as permitted sender)
Received: from [209.85.222.181] (HELO mail-pz0-f181.google.com)
 (209.85.222.181)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Dec 2009 00:15:50 +0000
Received: by pzk11 with SMTP id 11so2826031pzk.14
        for <ivy-user@ant.apache.org>; Mon, 30 Nov 2009 16:15:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :date:message-id:subject:from:to:content-type;
        bh=eWNTPYPL441f97wK5Sv8p2yfUJtAJLiXPSx7wAWaABA=;
        b=Q/Bgomu+4cODkMGDFacUWiLOBnNAYfGxMBN1Ix0nLqdir7XehVIvkmvZUM2SN2Z+pj
         3p/+rP/ra8WQWhKYvEH67jEEAl9B1bJpzyR90ZlykqhSMD4yVFeB7H7PeqD9dK/Gypdb
         cNpbLzVBUg4SoWlWtm0YYlJUf11B0XshzOIEI=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=kaf2RS2soKkLxlu4PPB3LWq9xqWMVE6MDCygm4cGCm+T/Qflz0+uLXwEANxVIUdYfB
         N30PC+Zhow2nhiRn3qJFJt7IyvSgMAWUEmgi/xynpBsxs0u2daaz5X7VwiTX6pWeIqrg
         gTEX/eGjani2eV8FhBgDKPM1wXdOmR0SpB0lI=
MIME-Version: 1.0
Received: by 10.140.173.2 with SMTP id v2mr291027rve.214.1259626528425; Mon,
	30 Nov 2009 16:15:28 -0800 (PST)
In-Reply-To: <7916a6a60911272231i76cfe2dekfdb169f979345489@mail.gmail.com>
References: <7916a6a60911272114o4ff04fd5p12b820b0883d19e6@mail.gmail.com>
	 <7916a6a60911272231i76cfe2dekfdb169f979345489@mail.gmail.com>
Date: Mon, 30 Nov 2009 16:15:28 -0800
Message-ID: <7916a6a60911301615t50372afr1cfdd4e38503199d@mail.gmail.com>
Subject: Re: install task from Maven repo misses TRANSITIVE source artifacts
From: Mitch Gitman <mgitman@gmail.com>
To: ivy-user@ant.apache.org
Content-Type: multipart/alternative; boundary=000e0cd158a8c6c6a804799fa73f
X-Virus-Checked: Checked by ClamAV on apache.org

--000e0cd158a8c6c6a804799fa73f
Content-Type: text/plain; charset=UTF-8

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?
>>
>
>

--000e0cd158a8c6c6a804799fa73f--