[
https://issues.apache.org/jira/browse/IVY-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas R. updated IVY-1130:
----------------------------
Attachment: IvyBugReport.zip
Contains the use case.
> When using confmappingoverride, resolving resolves configurations not asked
> for
> -------------------------------------------------------------------------------
>
> Key: IVY-1130
> URL: https://issues.apache.org/jira/browse/IVY-1130
> Project: Ivy
> Issue Type: Bug
> Affects Versions: 2.1.0-RC2
> Environment: Windows XP
> Reporter: Andreas R.
> Attachments: IvyBugReport.zip
>
>
> When using confmappingoverride=true, ivy does not behave like specified on
> http://ant.apache.org/ivy/history/latest-milestone/ivyfile/configurations.html
> (2.1.0-rc2).
> The last sentence states:
> "When you now resolve the conf2 configuration, you'll get the other2
> dependencies of your other-module",
> but our tests show that in that case you also get other1 dependencies as well.
> Below you can find the simplified use case we used to confirm that behavior.
> The use case is like on the specifications page, just the artifacts were
> added.
> Suppose we have "other-module" with the following ivy.xml:
> {code}
> <ivy-module version="2.0">
> <info organisation="org.example.bug" module="other-module"
> revision="1.0.0.0" />
> <configurations>
> <conf name="other1" />
> <conf name="other2" />
> </configurations>
>
> <publications>
> <artifact name="a1" conf="other1" />
> <artifact name="a2" conf="other2" />
> </publications>
> </ivy-module>
> {code}
> It contains two artifacts in two different configurations.
> The ivy.xml of "this-module" is as following:
> {code}
> <ivy-module version="2.0">
> <info organisation="org.example.bug" module="this-module"
> revision="1.0.0.0" />
> <configurations confmappingoverride="true"
> defaultconfmapping="conf1->other1;conf2->other2">
> <conf name="conf1" />
> <conf name="conf2" extends="conf1" />
> </configurations>
>
> <publications>
> <artifact name="b1" conf="conf1" />
> <artifact name="b2" conf="conf2" />
> </publications>
>
> <dependencies>
> <!-- build.xml just resolves conf2, but we still get a1.jar -->
> <dependency org="org.example.bug" name="other-module"
> rev="1.0.0.0" conf="conf1" />
> </dependencies>
> </ivy-module>
> {code}
> In build.xml of "this-module" just conf2 is resolved:
> {code}
> <project name="ivyconfmappingoverridetest_bugreport_thismodule"
> xmlns:ivy="antlib:org.apache.ivy.ant">
> <target name="retrieve">
> <ivy:retrieve conf="conf2" />
> </target>
> [...]
> </project>
> {code}
> but we still get both a1.jar and a2.jar in the lib directory
> {code}
> >dir this_module\lib /b
> a1-1.0.0.0.jar
> a2-1.0.0.0.jar
> {code}
> When we resolve/retrieve conf1 in "this-module", we want to get other1
> dependency of "other-module".
> When we resolve/retrieve conf2 in "this-module", we want to get other2
> dependency of "other-module".
> But when resolving/retrieving conf2, we get both other1 and other2
> dependencies of "other-module",
> although with confmappingoverride="true" we should just get other2
> dependencies.
> Unlike [Ivy bug 917|http://issues.apache.org/jira/browse/IVY-917],
> we do *not* expect that when using confmappingoverride just
> {code} <dependency name="other-module" conf="conf2->other2" />{code}
> should be constructed in memory instead of
> {code} <dependency name="other-module"
> conf="conf1->other1;conf2->other2" />{code}
> however, conf1->other1 mapping should not be used when we just ask the
> artifacts for conf2 to be resolved/retrieved.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
