Return-Path: 
 <ivy-user-return-1848-apmail-incubator-ivy-user-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-ivy-user-archive@locus.apache.org
Received: (qmail 5976 invoked from network); 23 Oct 2007 22:20:20 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 23 Oct 2007 22:20:20 -0000
Received: (qmail 54224 invoked by uid 500); 23 Oct 2007 22:20:07 -0000
Delivered-To: apmail-incubator-ivy-user-archive@incubator.apache.org
Received: (qmail 54066 invoked by uid 500); 23 Oct 2007 22:20:07 -0000
Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:ivy-user-help@incubator.apache.org>
List-Unsubscribe: <mailto:ivy-user-unsubscribe@incubator.apache.org>
List-Post: <mailto:ivy-user@incubator.apache.org>
List-Id: <ivy-user.incubator.apache.org>
Reply-To: ivy-user@incubator.apache.org
Delivered-To: mailing list ivy-user@incubator.apache.org
Received: (qmail 54057 invoked by uid 99); 23 Oct 2007 22:20:07 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Oct 2007 15:20:07 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [207.212.50.58] (HELO busybuddha.org) (207.212.50.58)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Oct 2007 22:20:10 +0000
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1])
	by busybuddha.org (8.14.1/8.14.1) with ESMTP id l9NM7ahB010865
	for <ivy-user@incubator.apache.org>; Tue, 23 Oct 2007 15:07:37 -0700
Message-ID: <471E7349.2070100@busybuddha.org>
Date: Tue, 23 Oct 2007 15:18:49 -0700
From: Anil Gangolli <anil@busybuddha.org>
User-Agent: Thunderbird 2.0.0.6 (X11/20070728)
MIME-Version: 1.0
To: ivy-user@incubator.apache.org
Subject: Re: Upgrade compatibility issue: 1.4.1 to 2.0.0-alpha2-incubating
References: <471E3993.4020904@busybuddha.org>
 <635a05060710231447r73b8912aw7c2cc3081088caa1@mail.gmail.com>
In-Reply-To: <635a05060710231447r73b8912aw7c2cc3081088caa1@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------080407010305070800060909"
X-Virus-Checked: Checked by ClamAV on apache.org

--------------080407010305070800060909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks.  I've filed the two issues I've encountered so far as:

https://issues.apache.org/jira/browse/IVY-630
https://issues.apache.org/jira/browse/IVY-631

I think both of them might be related to the chained resolution.   I'll 
try a bit more to isolate the problems and if I find anything will 
comment on the bugs.

--a.

Xavier Hanin wrote:
> On 10/23/07, Anil Gangolli <anil@busybuddha.org> wrote:
>   
>> I've been using Ivy since the time 1.4 came out.  Now, I'm trying to
>> upgrade one of my builds from 1.4.1 to 2.0.0-alpha2-incubating.
>>
>> I've hit the following compatibility issue which is blocking me.
>>
>> In 1.4.1, the filesystem resolver with an ivy pattern element seems to
>> have had no trouble finding (jar) artifacts that lacked a corresponding
>> ivy.xml.  In 2.0.0-alpha2-incubating, I'm getting resolution failures
>> with the complaint that the ivy.xml file isn't found.
>>
>> Here is my resolvers definition:
>>
>>   <resolvers>
>>     <!-- We define two resolvers and chain them to form our normal
>> resolver.
>>          The first is for thirdparty libraries, and the second is for
>> libraries we build ourselves.
>>          The chain looks first in thirdparty libraries, and then in
>> ours.  The first found is used. -->
>>     <filesystem name="thirdparty-libs">
>>       <ivy
>> pattern="${top.dir}/thirdparty/libraries/[module](-[revision])/ivy.xml"/>
>>       <!-- Patterns for thirdparty libs; in preferred resolution
>> ordering. -->
>>       <artifact
>> pattern="${top.dir
>> }/thirdparty/libraries/[module]-[revision]/dist/[artifact]-[revision].[ext]"/>
>>       <artifact
>> pattern="${top.dir
>> }/thirdparty/libraries/[module]-[revision]/dist/[artifact].[ext]"/>
>>       <artifact
>> pattern="${top.dir}/thirdparty/libraries/[module]/dist/[artifact].[ext]"/>
>>       <!-- Also supported patterns: resolution of artifacts grouped by
>> organization and module or only organization. -->
>>       <artifact
>> pattern="${top.dir
>> }/thirdparty/libraries/[organisation]/[module]/dist/[artifact].[ext]"/>
>>       <artifact
>> pattern="${top.dir
>> }/thirdparty/libraries/[organisation]/dist/[artifact].[ext]"/>
>>     </filesystem>
>>     <filesystem name="our-libs">
>>       <ivy pattern="${top.dir}/libraries/[module]/ivy.xml"/>
>>       <!-- Ivy bug or lack of understanding: using optional revision
>> (-[revision]) here doesn't work right.
>>            So we need two separate patterns. -->
>>       <artifact
>> pattern="${top.dir
>> }/libraries/[module]/build/dist/[organisation]-[artifact]-[revision].[ext]"/>
>>       <artifact
>> pattern="${top.dir
>> }/libraries/[module]/build/dist/[organisation]-[artifact].[ext]"/>
>>       <artifact
>> pattern="${top.dir
>> }/libraries/[module]/build/dist/[artifact]-[revision].[ext]"/>
>>       <artifact
>> pattern="${top.dir}/libraries/[module]/build/dist/[artifact].[ext]"/>
>>     </filesystem>
>>     <chain name="localtree" returnFirst="true">
>>       <resolver ref="thirdparty-libs"/>
>>       <resolver ref="our-libs"/>
>>     </chain>
>>   </resolvers>
>>
>> Here is an example resolution failure that didn't fail in 1.4.1:
>>
>> [ivy:retrieve]
>> [ivy:retrieve] :: problems summary ::
>> [ivy:retrieve] :::: WARNINGS
>> [ivy:retrieve]  problem while downloading ivy file:
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/thirdparty/libraries/log4j-
>> 1.2.9/ivy.xml
>> to /tmp/ivy13245xml:
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/thirdparty/libraries/log4j-
>> 1.2.9/ivy.xml
>> (No such file or directory)
>> [ivy:retrieve]          module not found: [ apache | log4j |
>> latest.integration ]
>> [ivy:retrieve]  ==== thirdparty-libs: tried
>> [ivy:retrieve]
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/thirdparty/libraries/log4j-
>> latest.integration/ivy.xml
>> [ivy:retrieve]
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/thirdparty/libraries/log4j-[revision]/ivy.xml
>> [ivy:retrieve]
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/thirdparty/libraries/log4j-
>> 1.2.9/ivy.xml
>> [ivy:retrieve]  ==== our-libs: tried
>> [ivy:retrieve]
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/libraries/log4j/ivy.xml
>> [ivy:retrieve]
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/libraries/log4j/ivy.xml
>> [ivy:retrieve]    -- artifact [ apache | log4j | latest.integration
>> ]/log4j.jar[jar]:
>> [ivy:retrieve]
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/libraries/log4j/build/dist/apache-
>> log4j-latest.integration.jar
>> [ivy:retrieve]
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/libraries/log4j/build/dist/apache-log4j-[revision].jar
>> [ivy:retrieve]
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/libraries/log4j/build/dist/apache-
>> log4j.jar
>> [ivy:retrieve]
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/libraries/log4j/build/dist/apache-
>> log4j.jar
>> [ivy:retrieve]
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/libraries/log4j/build/dist/log4j-
>> latest.integration.jar
>> [ivy:retrieve]
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/libraries/log4j/build/dist/log4j-[revision].jar
>> [ivy:retrieve]
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/libraries/log4j/build/dist/log4j.jar
>> [ivy:retrieve]
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/libraries/log4j/build/dist/log4j.jar
>> [ivy:retrieve]          ::::::::::::::::::::::::::::::::::::::::::::::
>> [ivy:retrieve]          ::          UNRESOLVED DEPENDENCIES         ::
>> [ivy:retrieve]          ::::::::::::::::::::::::::::::::::::::::::::::
>> [ivy:retrieve]          :: [ apache | log4j | latest.integration ]: not
>> found
>> [ivy:retrieve]          ::::::::::::::::::::::::::::::::::::::::::::::
>> [ivy:retrieve]
>> [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
>>
>> BUILD FAILED
>>
>> The jar artifact in question is at
>>
>>
>> /work/gangolli/p4work/XXX-branches/dev/buildsys/XXX/thirdparty/libraries/log4j-
>> 1.2.9/dist/log4j-1.2.9.jar
>>
>>
>> This resolution worked in 1.4.1, but not 2.0.0-alpha2.
>>
>> Is this expected?  Is there an option controlling this behavior?  Can I
>> alter my definitions to get this to work again without introducing
>> ivy.xml files for each artifact?
>>
>> Thanks in advance for any suggestions,
>>     
>
>
> It really sounds like a bug. What's really weird is that according to the
> log Ivy tries to locate the jar with the  'our-libs' resolver, but not with
> the thirdparty one.  This is maybe a bug in the chain, maybe with the
> returnFirst="true" I don't know. Could you please open an issue in jira:
> https://issues.apache.org/jira/browse/IVY
>
> Thanks,
>
> Xavier
>
> --a.
>   
>> anil@busybuddha.org
>> gangolli@apache.org
>>
>>
>>
>>
>>
>>     
>
>
>   


--------------080407010305070800060909--