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 <[EMAIL PROTECTED]> 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.
[EMAIL PROTECTED]
[EMAIL PROTECTED]
