Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 43150 invoked from network); 26 Nov 2007 07:45:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Nov 2007 07:45:41 -0000 Received: (qmail 99253 invoked by uid 500); 26 Nov 2007 07:45:28 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 98986 invoked by uid 500); 26 Nov 2007 07:45:28 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 98975 invoked by uid 99); 26 Nov 2007 07:45:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Nov 2007 23:45:28 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [88.198.46.98] (HELO indoqa.com) (88.198.46.98) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Nov 2007 07:45:27 +0000 Received: from [192.168.1.32] (chello062178239020.5.15.vie.surfer.at [62.178.239.20]) by indoqa.com (Postfix) with ESMTP id 6188525423A for ; Mon, 26 Nov 2007 09:01:23 +0100 (CET) Message-ID: <474A7983.1070300@apache.org> Date: Mon, 26 Nov 2007 08:45:07 +0100 From: Reinhard Poetz User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: XSP block dependencies References: <474687C7.6080100@gmx.de> <474998A2.1050205@apache.org> <474A4FFE.3070709@gmx.de> <474A58E3.6040303@gmx.de> <474A5FF1.5060808@dslextreme.com> In-Reply-To: <474A5FF1.5060808@dslextreme.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Ralph Goers wrote: > Is the cocoon build really trying to rely on transitive dependency > verions? Very bad idea. Versions of every dependency cocoon uses > directly or indirectly should be specified in the managedDependencies. The problem is that the groupId of the Avalon framework changed and that's the root of all evil in this case. We ever never need a dependency on Avalon 4.1.3 but how to express this in the managedDependencies section? The only chance for us is configuring "exclusions" but first you have to figure out that you have to do it at all (here the dependency module comes into play). I have also experienced very strange behaviour of the dependency resultion mechanism e.g. I exclude avalon-framework from being pulled in by commons-logging but then, when I use commons-beanutils, which pulls in commons-logging, the avalon-framework dependency is used again. TBH, I have no idea why the dependency resolution is still buggy after such a long time after the first final Maven 2 release :-/ -- Reinhard P�tz Managing Director, {Indoqa} GmbH http://www.indoqa.com/en/people/reinhard.poetz/ Member of the Apache Software Foundation Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org _________________________________________________________________________