Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of carlossg@gmail.com designates
 64.233.162.207 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=Uy9T1hek9zRozX3QIVa1peaEeHdKcg4xd/aWUYC2dzZAkRjLaGKLDhtn0kx7+yxj+Bt8aX3Ct85eDD4HcH3KdDfwqjHTdNtoAycJ15XNZA1Gf26iLdD9JL5jUmzUjJAeb96xJ9tqyoGq8gNnDMZ8QjJRWlj5jxjcXPkuVMSNuyg=
Message-ID: <1a5b6c410607050324h141ea84aocb9c918a257f7f11@mail.gmail.com>
Date: Wed, 5 Jul 2006 12:24:07 +0200
From: "Carlos Sanchez" <carlos@apache.org>
Sender: carlossg@gmail.com
To: rgoers@apache.org
Subject: Re: [RANT] This Maven thing is killing us....
Cc: "Maven Developers List" <dev@maven.apache.org>, dev@cocoon.apache.org
In-Reply-To: <44AB5849.2030900@dslextreme.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: 
 <FDD5D99066749040AF9098A720E9897701CA1830@CIWMEXZSA0E.ex.ordersx.org>
	 <98e4f1cd0607040434k1c0f7ddeo8e9ddf0899c15b7e@mail.gmail.com>
	 <1a5b6c410607040553r6c20b441j81ec638465d9f10d@mail.gmail.com>
	 <44AAD6C3.3050107@dslextreme.com>
	 <1a5b6c410607041722o2c9e0111g6983003db99ea937@mail.gmail.com>
	 <44AB5849.2030900@dslextreme.com>

On 7/5/06, Ralph Goers <Ralph.Goers@dslextreme.com> wrote:
>
>
> Carlos Sanchez wrote:
> >
> > Yes you can, it's not the best way to do it but you can, by adding
> > explicitly the dependency with the versoin you want to your pom. In
> > the very worst case you have to add all transitive deendencies to your
> > pom, like in Maven 1.
> That is so impractical as to be nonsensical. Our Configuration
> Management folks require that all projects use the same dependencies
> from the top to the bottom. For example, we build our base set of
> frameworks with one multiproject build, then a higher level of
> frameworks, and then finally the product itself. Each of these must be
> built and unit tested with the same third party jars. Furthermore, the
> product can consist of a war and one or more ejb's which may all be
> packaged in an ear. These must also all have all the same versions of
> the jars. The solution you propose makes that tedious, error prone, and
> would require our CM folks to manually inspect every pom to insure
> nothing is done improperly. At least with Maven 1 we can have a
> build.properties that all projects share.  In our case, the ideal
> solution in Maven 2 would be to have a "master" pom with nothing in it
> but a dependencyManagement section (with something like override="true"
> set as an attribute) that all our projects would reference.

so... you can do it.
In m1 anybody can override the build.properties as in m2 they can put
a different version.

i'm not saying it's the right solution but while is not implemented
you can still do it. There's a limited number of hours in the day to
do all the things we want to do ;)

>
> Ralph
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride