ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anil Gangolli <a...@busybuddha.org>
Subject Re: Upgrade compatibility issue: 1.4.1 to 2.0.0-alpha2-incubating
Date Tue, 23 Oct 2007 21:23:01 GMT
Thanks for the suggestion.   I tried using allownomd="true" after 
reading your suggestion, but it didn't seem to change the behavior at 
all.  I have added a second resolver to the chain with the same artifact 
patterns and no ivy element and that seems to have worked.

I've now hit my second compatibility issue though, and this seems like a 
bug.   I have an ivy:retrieve invocation that looks like this:

<ivy:retrieve pattern="${deps.dir}/[conf]/[originalname].[ext]" 
sync="true"/>


The retrieval is writing many of the resolved artifacts to the proper 
directory with the name (verbatim): "[originalname].jar" rather than 
substituting the actual originalname of the jar from the result of the 
resolution; it is happening in cases where the artifact was found by 
the  last resolver in the chain (the "our-libs" filesystem resolver 
defined below).   I'm not sure if that is pertinent or not.  There is an 
ivy file for these resolved modules.  And this substitution worked with 
1.4.1.

Should I file a bug or is this due to my misuse/misunderstanding?

Separate question: where would I file a bug?

--a.




Gilles Scokart wrote:
> Sounds to me like a bug.
>
> Did you tried to set allownomd="true" for your resolver? (I know It should
> be the default value according to the doc).
>
>
> Gilles
>
> 2007/10/23, Anil Gangolli <anil@busybuddha.org>:
>   
>> 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,
>> --a.
>>
>> anil@busybuddha.org
>> gangolli@apache.org
>>
>>
>>
>>
>>
>>     
>
>
>   


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