From notifications-return-10152-apmail-ant-notifications-archive=ant.apache.org@ant.apache.org Mon Sep 28 16:37:41 2009
Return-Path:
Delivered-To: apmail-ant-notifications-archive@minotaur.apache.org
Received: (qmail 11584 invoked from network); 28 Sep 2009 16:37:41 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 28 Sep 2009 16:37:41 -0000
Received: (qmail 77684 invoked by uid 500); 28 Sep 2009 16:37:41 -0000
Delivered-To: apmail-ant-notifications-archive@ant.apache.org
Received: (qmail 77625 invoked by uid 500); 28 Sep 2009 16:37:41 -0000
Mailing-List: contact notifications-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@ant.apache.org
Delivered-To: mailing list notifications@ant.apache.org
Received: (qmail 77611 invoked by uid 99); 28 Sep 2009 16:37:41 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Sep 2009 16:37:41 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=10.0
tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Sep 2009 16:37:37 +0000
Received: from brutus (localhost [127.0.0.1])
by brutus.apache.org (Postfix) with ESMTP id EF095234C004
for ; Mon, 28 Sep 2009 09:37:15 -0700 (PDT)
Message-ID: <1707000894.1254155835964.JavaMail.jira@brutus>
Date: Mon, 28 Sep 2009 09:37:15 -0700 (PDT)
From: "Andreas R. (JIRA)"
To: notifications@ant.apache.org
Subject: [jira] Created: (IVY-1130) When using confmappingoverride,
resolving resolves configurations not asked for
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org
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.
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}
{code}
It contains two artifacts in two different configurations.
The ivy.xml of "this-module" is as following:
{code}
{code}
In build.xml of "this-module" just conf2 is resolved:
{code}
[...]
{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} {code}
should be constructed in memory instead of
{code} {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.