From dev-return-88244-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Tue Jul 04 13:38:02 2006 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 27825 invoked from network); 4 Jul 2006 13:38:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Jul 2006 13:38:00 -0000 Received: (qmail 65822 invoked by uid 500); 4 Jul 2006 13:37:57 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 65774 invoked by uid 500); 4 Jul 2006 13:37:56 -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 65762 invoked by uid 99); 4 Jul 2006 13:37:56 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Jul 2006 06:37:56 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [192.6.10.60] (HELO tobor.hpl.hp.com) (192.6.10.60) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Jul 2006 06:37:55 -0700 Received: from localhost (localhost [127.0.0.1]) by tobor.hpl.hp.com (Postfix) with ESMTP id D88F0370AE; Tue, 4 Jul 2006 14:37:33 +0100 (BST) X-Virus-Scanned: amavisd-new at hplb.hpl.hp.com Received: from tobor.hpl.hp.com ([127.0.0.1]) by localhost (tobor.hpl.hp.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SqCU2KQgqaif; Tue, 4 Jul 2006 14:37:32 +0100 (BST) Received: from kropotkin.hpl.hp.com (kropotkin.hpl.hp.com [16.25.191.14]) by tobor.hpl.hp.com (Postfix) with ESMTP id 85EEA370AA; Tue, 4 Jul 2006 14:37:30 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by kropotkin.hpl.hp.com (Postfix) with ESMTP id 8CEF755BD; Tue, 4 Jul 2006 14:37:30 +0100 (BST) X-Virus-Scanned: amavisd-new at kropotkin.hpl.hp.com Received: from kropotkin.hpl.hp.com ([127.0.0.1]) by localhost (kropotkin.hpl.hp.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AoCV1DNk5Zt6; Tue, 4 Jul 2006 14:37:26 +0100 (BST) Received: from timmay.hpl.hp.com (timmay.hpl.hp.com [16.25.171.20]) by kropotkin.hpl.hp.com (Postfix) with ESMTP id DA81EB936; Tue, 4 Jul 2006 14:37:25 +0100 (BST) Received: from [16.25.171.182] (chamonix.hpl.hp.com [16.25.171.182]) by timmay.hpl.hp.com (8.13.2/8.13.2) with ESMTP id k64DbILa029826; Tue, 4 Jul 2006 14:37:18 +0100 (BST) Message-ID: <44AA6F0E.8040908@apache.org> Date: Tue, 04 Jul 2006 14:37:18 +0100 From: Steve Loughran User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Maven Developers List CC: dev@cocoon.apache.org Subject: Re: [RANT] This Maven thing is killing us.... References: <98e4f1cd0607040434k1c0f7ddeo8e9ddf0899c15b7e@mail.gmail.com> <1a5b6c410607040553r6c20b441j81ec638465d9f10d@mail.gmail.com> In-Reply-To: <1a5b6c410607040553r6c20b441j81ec638465d9f10d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-HPLB-IMAP-MailScanner-Information: Please contact the Helpdesk for more information X-HPLB-IMAP-MailScanner: Found to be clean X-HPLB-IMAP-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 5) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Carlos Sanchez wrote: > The repository is as good as the users/projects make it. There's no > difference at all with using ant and including the wrong jars, maybe > the problem is that how to fix it in maven is not as easy as in ant. > > If project A says it depends on B 1.0 and C says it depends on B 1.1, > there's a conflict in Maven, Ant and anything you want to use, the > difference is that Maven tries to do it for you, but you still can > override that behaviour. > It seems to me that the difference in ant, the duty to set up your classpath belongs to the project alone, so you, the build.xml author are the only one who can make a mess of your CP. However, on any system with transitive dependencies, you are ceding control of your classpath to other programs out there. Even if you think you know exactly what the dependency graph of your app is, an update to a new version of any your dependencies can pull in new metadata, with a new set of dependencies, and potentially a new classpath. This is not a maven-specific problem; anything that supports transitive dependency logic can suffer from it. Gump and Ivy could, though in both cases the descriptors tend to be hand-written tuned to not exhibit the problem. (in gump most projects dont export dependencies, as the default is compile-time-only). > Right now we are in a good position with a huge number of users trying > and testing the metadata in the repository, and forcing projects to > support maven by providing good data. That still assumes that transitive dependencies are a good thing, and that perfect metadata is achievable. I'm not sure about either of those. I also think they're straying dangerously close to one of the big software engineering tar-pits: versioning. -steve