Return-Path: 
 <notifications-return-22174-apmail-ant-notifications-archive=ant.apache.org@ant.apache.org>
X-Original-To: apmail-ant-notifications-archive@minotaur.apache.org
Delivered-To: apmail-ant-notifications-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 429DAF5B0
	for <apmail-ant-notifications-archive@minotaur.apache.org>;
 Tue,  7 May 2013 10:39:29 +0000 (UTC)
Received: (qmail 43787 invoked by uid 500); 7 May 2013 10:39:29 -0000
Delivered-To: apmail-ant-notifications-archive@ant.apache.org
Received: (qmail 43600 invoked by uid 500); 7 May 2013 10:39:24 -0000
Mailing-List: contact notifications-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:notifications-help@ant.apache.org>
List-Unsubscribe: <mailto:notifications-unsubscribe@ant.apache.org>
List-Post: <mailto:notifications@ant.apache.org>
List-Id: <notifications.ant.apache.org>
Reply-To: dev@ant.apache.org
Delivered-To: mailing list notifications@ant.apache.org
Received: (qmail 42978 invoked by uid 99); 7 May 2013 10:39:23 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 May 2013 10:39:23 +0000
Date: Tue, 7 May 2013 10:39:23 +0000 (UTC)
From: "Vitaliy Sapounov (JIRA)" <jira@apache.org>
To: notifications@ant.apache.org
Message-ID: <JIRA.12646379.1367916927773.279326.1367923163354@arcas>
In-Reply-To: <JIRA.12646379.1367916927773@arcas>
References: <JIRA.12646379.1367916927773@arcas>
Subject: [jira] [Comment Edited] (IVY-1422) Dependency "force" does not work
 if comes from extended module
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/IVY-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13650639#comment-13650639 ] 

Vitaliy Sapounov edited comment on IVY-1422 at 5/7/13 10:38 AM:
----------------------------------------------------------------

The question is, therefore, why the 

{code}parent.getResolvedId().equals(dd.getParentRevisionId()){code} 

check is needed?

Also, to list, some ways of fixing could be:
 * remove the check (that is most likely incorrect), OR
 * when merging dependencies from base module, change its parent module ID to extended in {{XmlModuleDescriptorParser.mergeDependencies()}}, OR 
 * do an additional check in LatestConflictManager, something like
{code}parent.getResolvedId().equals(dd.getParentRevisionId()) || parent.getResolvedId() ~extends~ dd.getParentRevisionId(){code}
                
      was (Author: vitaliy.sapounov@gmail.com):
    The question is, therefore, why the 

{code}parent.getResolvedId().equals(dd.getParentRevisionId()){code} 

check is needed?

Also, to list, naive way of fixing could be:
 * remove the check (that is most likely incorrect), OR
 * when merging dependencies from base module, change its parent module ID to extended in {{XmlModuleDescriptorParser.mergeDependencies()}}, OR 
 * do an additional check in LatestConflictManager, something like
{code}parent.getResolvedId().equals(dd.getParentRevisionId()) || parent.getResolvedId() ~extends~ dd.getParentRevisionId(){code}
                  
> Dependency "force" does not work if comes from extended module
> --------------------------------------------------------------
>
>                 Key: IVY-1422
>                 URL: https://issues.apache.org/jira/browse/IVY-1422
>             Project: Ivy
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.3.0
>            Reporter: Vitaliy Sapounov
>
> *ENVIRONMENT*
> We have a project that uses several Ivy modules:
> 1) There is a base module that declares dependency on "vendorlib", revision 1.0, with "force" attribute (the whole purpose of the module is to guarantee the "vendorlib" revision):
> {code:xml}
> <ivy-module>
>     <info organisation="com.mycompany" module="base" revision="trunk"/>
>     <dependencies>
>         <dependency org="com.vendor" name="vendorlib" rev="1.0" force="true"/>
>     </dependencies>
> </ivy-module>
> {code}
> 2) There is an extending module that also includes our library "mylib":
> {code:xml}
> <ivy-module>
>     <info organisation="com.mycompany" module="extending" revision="trunk">
>         <extends organisation="com.mycompany" module="base" revision="trunk"/>
>     </info>
>     <dependencies>
>         <dependency org="com.mycompany" name="mylib" rev="trunk"/>
>     </dependencies>
> </ivy-module>
> {code}
> 3) Finally, our library "mylib" also depends on "vendorlib", revision 2.0 (i.e. there is another dependency on "vendorlib" with another revision):
> {code:xml}
> <ivy-module>
>     <info organisation="com.mycompany" module="mylib" revision="trunk"/>
>     <dependencies>
>         <dependency org="com.vendor" name="vendorlib" rev="2.0"/>
>     </dependencies>
> </ivy-module>
> {code}
> 4) We use "latest-revision" conflict manager in ivysettings.xml.
> *PROBLEM*
> Despite the "force" attribute in base module for "vendorlib", latest revision (2.0) of "vendorlib" is selected by the conflict manager for the extended module.
> *ROOT CAUSE*
> {{LatestConflictManager}} has the following code:
> {code}
>     public Collection resolveConflicts(IvyNode parent, Collection conflicts) {
>         if (conflicts.size() < 2) {
>             return conflicts;
>         }
>         for (Iterator iter = conflicts.iterator(); iter.hasNext();) {
>             IvyNode node = (IvyNode) iter.next();
>             DependencyDescriptor dd = node.getDependencyDescriptor(parent);
>             if (dd != null && dd.isForce()
> >>>>>>>>>                    && parent.getResolvedId().equals(dd.getParentRevisionId())) {
>                 return Collections.singleton(node);
>             }
>         }
> {code}
> Note ">>>>" line: since "vendorlib" with "force" attribute comes from the base module, {{dd.getParentRevisionId()}} returns "com.mycompany#base;trunk", but {{parent.getResolvedId()}} returns "com.mycompany#extended;trunk", thus the last comparison  returns "false" and "force" is lost.
> If we move dependency with "force" to the extended module, it will work.
> *REAL-LIFE APPLICABILITY*
> We use the "base" module as a template that fixes versions of libraries provided by the J2EE application server we use. Based on that template, we create a number of extending web applications that guarantee to use the libs that the application server provides. (The actual use case is slightly more complicated, as e.g. "mylib" declares dependency on "vendorlib" version range it supports, e.g. "[2.0,5.7]" range.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira