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