You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Anil Gangolli <an...@busybuddha.org> on 2007/10/23 20:12:35 UTC
Upgrade compatibility issue: 1.4.1 to 2.0.0-alpha2-incubating
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
Re: Upgrade compatibility issue: 1.4.1 to 2.0.0-alpha2-incubating
Posted by Anil Gangolli <an...@busybuddha.org>.
I managed to get past this by adding another resolver to my chain that
just duplicates my thirdparty-libs resolver, but excludes the ivy element.
--a.
Anil Gangolli 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,
> --a.
>
> anil@busybuddha.org
> gangolli@apache.org
>
>
>
>
>
Re: Upgrade compatibility issue: 1.4.1 to 2.0.0-alpha2-incubating
Posted by Anil Gangolli <an...@busybuddha.org>.
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 <an...@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
>>
>>
>>
>>
>>
>>
>
>
>
Re: Upgrade compatibility issue: 1.4.1 to 2.0.0-alpha2-incubating
Posted by Xavier Hanin <xa...@gmail.com>.
On 10/23/07, Anil Gangolli <an...@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
>
>
>
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: Upgrade compatibility issue: 1.4.1 to 2.0.0-alpha2-incubating
Posted by Anil Gangolli <an...@busybuddha.org>.
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 <an...@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
>>
>>
>>
>>
>>
>>
>
>
>
Re: Upgrade compatibility issue: 1.4.1 to 2.0.0-alpha2-incubating
Posted by Gilles Scokart <gs...@gmail.com>.
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 <an...@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
>
>
>
>
>
--
Gilles SCOKART