ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas R. (JIRA)" <j...@apache.org>
Subject [jira] Updated: (IVY-1130) When using confmappingoverride, resolving resolves configurations not asked for
Date Mon, 28 Sep 2009 16:40:16 GMT

     [ 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.


Mime
View raw message