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