From dev-return-98416-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Thu Feb 07 16:13:14 2008 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 88426 invoked from network); 7 Feb 2008 16:13:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Feb 2008 16:13:14 -0000 Received: (qmail 76662 invoked by uid 500); 7 Feb 2008 16:13:05 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 76496 invoked by uid 500); 7 Feb 2008 16:13:05 -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 76485 invoked by uid 99); 7 Feb 2008 16:13:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Feb 2008 08:13:04 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [195.186.18.82] (HELO tr13.bluewin.ch) (195.186.18.82) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Feb 2008 16:12:35 +0000 Received: from [192.168.0.144] (190.43.217.241) by tr13.bluewin.ch (Bluewin 7.3.122) (authenticated as a.nathaniel) id 4795C318002A8DFF for dev@cocoon.apache.org; Thu, 7 Feb 2008 16:12:41 +0000 Subject: Re: XSP block dependencies From: Alfred Nathaniel Reply-To: a.nathaniel@bluewin.ch To: dev@cocoon.apache.org In-Reply-To: <474A7983.1070300@apache.org> References: <474687C7.6080100@gmx.de> <474998A2.1050205@apache.org> <474A4FFE.3070709@gmx.de> <474A58E3.6040303@gmx.de> <474A5FF1.5060808@dslextreme.com> <474A7983.1070300@apache.org> Content-Type: text/plain Date: Thu, 07 Feb 2008 17:11:02 +0100 Message-Id: <1202400662.5828.26.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Mon, 2007-11-26 at 08:45 +0100, Reinhard Poetz wrote: > 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 :-/ I now added exclusion rules to all our explicit dependencies which pick up the old avalon-framework through transitive dependencies. Although that brings us out of jar hell for the moment, it is only a stop-gap solution. Any new explicit dependencies could bring back the problem. For once, it is not a fault of m2. It is doing the right thing. The problem is in the avalon-framework poms changing groupId and artefactId between versions. Maven should, however, provide a mechanism to deal with this globally in a parent pom. Here is the pedestrian approach I used to find the places where the exclusions needed to be inserted: 1.) rm -r $M2_REPO/avalon-framework 2.) fgrep avalon-framework-4 `find trunk -name .classpath` 3.) cd to first project directory containing a matching .classpath 4.) mvn -X eclipse:clean eclipse:eclipse 5.) Identify the explicit dependency with triggers the download of avalon-framework-4.1.3.pom. 6.) Add exclusion rule to that explicit dependency, e.g.: commons-httpclient commons-httpclient + + + avalon-framework + avalon-framework + + 7.) mvn eclipse:clean eclipse:eclipse 8.) Rinse and repeat. Cheers, Alfred.