Return-Path: 
 <notifications-return-12003-apmail-ant-notifications-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-notifications-archive@minotaur.apache.org
Received: (qmail 202 invoked from network); 26 Mar 2010 22:28:48 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 26 Mar 2010 22:28:48 -0000
Received: (qmail 32053 invoked by uid 500); 26 Mar 2010 22:28:48 -0000
Delivered-To: apmail-ant-notifications-archive@ant.apache.org
Received: (qmail 32017 invoked by uid 500); 26 Mar 2010 22:28:48 -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 32003 invoked by uid 99); 26 Mar 2010 22:28:48 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Mar 2010 22:28:48 +0000
X-ASF-Spam-Status: No, hits=-1148.5 required=10.0
	tests=ALL_TRUSTED,AWL
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; Fri, 26 Mar 2010 22:28:47 +0000
Received: from brutus.apache.org (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id 2EAD2234C4EF
	for <notifications@ant.apache.org>; Fri, 26 Mar 2010 22:28:27 +0000 (UTC)
Message-ID: <1465304255.520551269642507177.JavaMail.jira@brutus.apache.org>
Date: Fri, 26 Mar 2010 22:28:27 +0000 (UTC)
From: "Maarten Coene (JIRA)" <jira@apache.org>
To: notifications@ant.apache.org
Subject: [jira] Commented: (IVY-1178) Transitive dependencies resolutions
 issue when eviction is triggered
In-Reply-To: <914436014.484151269507327136.JavaMail.jira@brutus.apache.org>
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-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850380#action_12850380 ] 

Maarten Coene commented on IVY-1178:
------------------------------------

If you generate an ivy:report after your ivy:resolve you might see where these log4j dependencies are coming from...

> Transitive dependencies resolutions issue when eviction is triggered
> --------------------------------------------------------------------
>
>                 Key: IVY-1178
>                 URL: https://issues.apache.org/jira/browse/IVY-1178
>             Project: Ivy
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.1.0
>         Environment: Linux / ant 1.7.0
>            Reporter: david herviou
>
> Originally described in ivy-user list : http://old.nabble.com/Transitive-resolving-issue---td27984462.html
> Here just a part of the discussion that explain the problem and the temporary work around :
> Consider the following use case :
> moduleA has one of its dependencies like this : 
>  <dependency org="log4j" name="log4j" rev="1.2.14" transitive="false"/> 
> moduleB has one of its dependencies like this : 
>  <dependency org="log4j" name="log4j" rev="1.2.15" transitive="false"/> 
> While moduleC use moduleA and moduleB I have something like this : 
>  <dependency org="moduleA.org" name="moduleA" rev="moduleA.rev"/> 
>  <dependency org="moduleB.org" name="moduleB" rev="moduleB.rev"/> 
> This seems to be very banal BUT, when running the ivy:resolve task the 
> log4j-1.2.15 evicts the log4j-1.2.14 which seems to be a good thing! 
> but thereafter the resolve task does not consider the transitivity has false 
> and try to resolve all the dependencies of log4j-1.2.15 
> If I remove moduleA.org and use only moduleB.org then the resolve task 
> behave correctly (I mean there is no resolution of transitives 
> dependencies). 
> The reverse case is also true. 
> A work-around is available by resolving conflict explicitly with something like :
>  <conflict org="moduleA.org" module="moduleA" rev="moduleA.rev"/>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.