You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-commits@incubator.apache.org by "Anil Gangolli (JIRA)" <ji...@apache.org> on 2007/10/23 22:02:51 UTC
[jira] Created: (IVY-630) Resolution failure when no ivy.xml file
present
Resolution failure when no ivy.xml file present
-----------------------------------------------
Key: IVY-630
URL: https://issues.apache.org/jira/browse/IVY-630
Project: Ivy
Issue Type: Bug
Affects Versions: 2.0.0-alpha-2
Environment: 2.0.0-alpha2-incubating
Ant 1.7.0
Sun JDK 1.5.0_12
Reporter: Anil Gangolli
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.
Additional information:
- explicitly setting allownomd=true on the thirdparty-libs resolver did not seem to have helped.
- adding another resolver to the chain "thirdparty-libs-noivy" with the same artifact patterns but with no ivy element worked as a workaround to this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-630) Resolution failure when no ivy.xml file
present
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maarten Coene reassigned IVY-630:
---------------------------------
Assignee: Maarten Coene
> Resolution failure when no ivy.xml file present
> -----------------------------------------------
>
> Key: IVY-630
> URL: https://issues.apache.org/jira/browse/IVY-630
> Project: Ivy
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha-2
> Environment: 2.0.0-alpha2-incubating
> Ant 1.7.0
> Sun JDK 1.5.0_12
> Reporter: Anil Gangolli
> Assignee: Maarten Coene
> Fix For: 2.0
>
> Attachments: ivytest-630.tgz
>
>
> 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.
> Additional information:
> - explicitly setting allownomd=true on the thirdparty-libs resolver did not seem to have helped.
> - adding another resolver to the chain "thirdparty-libs-noivy" with the same artifact patterns but with no ivy element worked as a workaround to this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (IVY-630) Resolution failure when no
ivy.xml file present
Posted by "Anil Gangolli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540955 ]
gangolli edited comment on IVY-630 at 11/7/07 6:51 PM:
------------------------------------------------------------
Test case tarball.
Instructions here and in the included README.
cd /tmp
tar xvfz ivytest-630.tgz
cd ivytest-630
tar xvfz apache-ivy-2.0.0-alpha2-incubating-bin-with-deps.tar.gz
mv apache-ivy-2.0.0-alpha2-incubating ivydist
ant
Resolution fails due to the missing ivy.xml.
If you comment out the ivy file pattern from the
resolver in the ivy_settings.xml it will begin to work.
This resolution should succeed with the ivy file pattern present
even without the ivy.xml file present with the resolved artifact.
The same test case succeeds with Ivy 1.4.1. It fails in current Ivy 2.x
even if allownomd="true" is set on the resolver.
was (Author: gangolli):
Test case tarball. See instructions in comments.
> Resolution failure when no ivy.xml file present
> -----------------------------------------------
>
> Key: IVY-630
> URL: https://issues.apache.org/jira/browse/IVY-630
> Project: Ivy
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha-2
> Environment: 2.0.0-alpha2-incubating
> Ant 1.7.0
> Sun JDK 1.5.0_12
> Reporter: Anil Gangolli
> Fix For: 2.0
>
> Attachments: ivytest-630.tgz
>
>
> 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.
> Additional information:
> - explicitly setting allownomd=true on the thirdparty-libs resolver did not seem to have helped.
> - adding another resolver to the chain "thirdparty-libs-noivy" with the same artifact patterns but with no ivy element worked as a workaround to this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-630) Resolution failure when no ivy.xml file
present
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540532 ]
Maarten Coene commented on IVY-630:
-----------------------------------
I couldn't reproduce this issue.
Could you provide a test case or give more information like:
- your ivy.xml file
- the build.xml file (or the part that does the retrieve)
- ant debug logs
Maarten
> Resolution failure when no ivy.xml file present
> -----------------------------------------------
>
> Key: IVY-630
> URL: https://issues.apache.org/jira/browse/IVY-630
> Project: Ivy
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha-2
> Environment: 2.0.0-alpha2-incubating
> Ant 1.7.0
> Sun JDK 1.5.0_12
> Reporter: Anil Gangolli
> Fix For: 2.0
>
>
> 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.
> Additional information:
> - explicitly setting allownomd=true on the thirdparty-libs resolver did not seem to have helped.
> - adding another resolver to the chain "thirdparty-libs-noivy" with the same artifact patterns but with no ivy element worked as a workaround to this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-630) Resolution failure when no ivy.xml file
present
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maarten Coene resolved IVY-630.
-------------------------------
Resolution: Fixed
Fix Version/s: (was: 2.0)
2.0.0-beta-1
It should be fixed in trunk now.
Could you try it out?
> Resolution failure when no ivy.xml file present
> -----------------------------------------------
>
> Key: IVY-630
> URL: https://issues.apache.org/jira/browse/IVY-630
> Project: Ivy
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha-2
> Environment: 2.0.0-alpha2-incubating
> Ant 1.7.0
> Sun JDK 1.5.0_12
> Reporter: Anil Gangolli
> Assignee: Maarten Coene
> Fix For: 2.0.0-beta-1
>
> Attachments: ivytest-630.tgz
>
>
> 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.
> Additional information:
> - explicitly setting allownomd=true on the thirdparty-libs resolver did not seem to have helped.
> - adding another resolver to the chain "thirdparty-libs-noivy" with the same artifact patterns but with no ivy element worked as a workaround to this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-630) Resolution failure when no ivy.xml file
present
Posted by "Anil Gangolli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Anil Gangolli updated IVY-630:
------------------------------
Attachment: ivytest-630.tgz
Test case tarball. See instructions in comments.
> Resolution failure when no ivy.xml file present
> -----------------------------------------------
>
> Key: IVY-630
> URL: https://issues.apache.org/jira/browse/IVY-630
> Project: Ivy
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha-2
> Environment: 2.0.0-alpha2-incubating
> Ant 1.7.0
> Sun JDK 1.5.0_12
> Reporter: Anil Gangolli
> Fix For: 2.0
>
> Attachments: ivytest-630.tgz
>
>
> 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.
> Additional information:
> - explicitly setting allownomd=true on the thirdparty-libs resolver did not seem to have helped.
> - adding another resolver to the chain "thirdparty-libs-noivy" with the same artifact patterns but with no ivy element worked as a workaround to this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-630) Resolution failure when no ivy.xml file
present
Posted by "Anil Gangolli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540956 ]
Anil Gangolli commented on IVY-630:
-----------------------------------
Note: I tried the results of an ivy trunk build on this test case and it also fails, so you can use trunk for testing and debugging this.
> Resolution failure when no ivy.xml file present
> -----------------------------------------------
>
> Key: IVY-630
> URL: https://issues.apache.org/jira/browse/IVY-630
> Project: Ivy
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha-2
> Environment: 2.0.0-alpha2-incubating
> Ant 1.7.0
> Sun JDK 1.5.0_12
> Reporter: Anil Gangolli
> Fix For: 2.0
>
> Attachments: ivytest-630.tgz
>
>
> 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.
> Additional information:
> - explicitly setting allownomd=true on the thirdparty-libs resolver did not seem to have helped.
> - adding another resolver to the chain "thirdparty-libs-noivy" with the same artifact patterns but with no ivy element worked as a workaround to this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-630) Resolution failure when no ivy.xml file
present
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xavier Hanin updated IVY-630:
-----------------------------
Fix Version/s: 2.0
Description:
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.
Additional information:
- explicitly setting allownomd=true on the thirdparty-libs resolver did not seem to have helped.
- adding another resolver to the chain "thirdparty-libs-noivy" with the same artifact patterns but with no ivy element worked as a workaround to this issue.
was:
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.
Additional information:
- explicitly setting allownomd=true on the thirdparty-libs resolver did not seem to have helped.
- adding another resolver to the chain "thirdparty-libs-noivy" with the same artifact patterns but with no ivy element worked as a workaround to this issue.
> Resolution failure when no ivy.xml file present
> -----------------------------------------------
>
> Key: IVY-630
> URL: https://issues.apache.org/jira/browse/IVY-630
> Project: Ivy
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha-2
> Environment: 2.0.0-alpha2-incubating
> Ant 1.7.0
> Sun JDK 1.5.0_12
> Reporter: Anil Gangolli
> Fix For: 2.0
>
>
> 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.
> Additional information:
> - explicitly setting allownomd=true on the thirdparty-libs resolver did not seem to have helped.
> - adding another resolver to the chain "thirdparty-libs-noivy" with the same artifact patterns but with no ivy element worked as a workaround to this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.