Return-Path: 
 <dev-return-94186-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 55326 invoked from network); 11 Apr 2007 19:07:51 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 11 Apr 2007 19:07:51 -0000
Received: (qmail 9007 invoked by uid 500); 11 Apr 2007 19:07:55 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 8922 invoked by uid 500); 11 Apr 2007 19:07:55 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 8911 invoked by uid 99); 11 Apr 2007 19:07:55 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2007 12:07:55 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of ap-cocoon-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2007 12:07:48 -0700
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1HbiA2-00007y-Ka
	for dev@cocoon.apache.org; Wed, 11 Apr 2007 21:07:18 +0200
Received: from d5153ca7c.access.telenet.be ([81.83.202.124])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <dev@cocoon.apache.org>; Wed, 11 Apr 2007 21:07:18 +0200
Received: from jheymans by d5153ca7c.access.telenet.be with local (Gmexim 0.1
 (Debian))
        id 1AlnuQ-0007hv-00
        for <dev@cocoon.apache.org>; Wed, 11 Apr 2007 21:07:18 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: dev@cocoon.apache.org
From: Jorg Heymans <jheymans@apache.org>
Subject: Re: building trunk.
Date: Wed, 11 Apr 2007 21:07:22 +0200
Lines: 35
Message-ID: <evjbku$u4m$1@sea.gmane.org>
References: <4619E0E5.8000202@dslextreme.com>
 <4619EA81.2000106@dslextreme.com> <461A62C9.50103@apache.org>
 <461AF48D.5090203@dslextreme.com> <461B2EBF.3020801@apache.org>
 <461B393B.1070704@dslextreme.com> <461B3D27.5030706@apache.org>
 <evghni$cht$1@sea.gmane.org> <461C7099.8040002@dslextreme.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: d5153ca7c.access.telenet.be
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
In-Reply-To: <461C7099.8040002@dslextreme.com>
Sender: news <news@sea.gmane.org>
X-Virus-Checked: Checked by ClamAV on apache.org

Ralph Goers wrote:

> No.  If you reference a transitive dependency than the 
> dependencyManagement of its parent will be used to provide the version. 
> However, if the project being built defines the dependency, either in 
> its pom or in a parent's dependencyManagement, than that will be used 
> instead.

...

>> I don't think any of these options is desired. Our main goal should be 
>> to keep our own dependency tree as clean as possible, ie <exclude> 
>> transitive dependencies in 3rd party libs that are clearly 
>> wrong/optional etc.
> Have you looked at the dependency analysis report? It is a mess.

...

>> Example: say i have a webapp pom that includes
>> - cocoon-core (which has CL 1.1)
>> - cocoon-thread-impl (which has CL 1.0.4)
>>
>> then maven will just select CL 1.1 for inclusion, not both. If i 
>> however define in my webapp pom CL 1.0.4 then it will select only that.
> Wrong. Maven will choose the "nearest" which might be 1.1 or 1.0.4. The 
> bottom line is you can never be sure.  dependencyManagement allows you 
> to define what versions should be used wherever they appear in the project.
> 

Gosh and i thought maven was supposed to make dependencyManagement easy :-)


Jorg

(i stand corrected on all points btw, thanks for explaining the details)