cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist <lundquist.m...@gmail.com>
Subject Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Date Thu, 25 Jan 2007 22:30:17 GMT

On Jan 25, 2007, at 11:46 AM, Jorg Heymans wrote:

> How about having 2 local repositories ? Put a settings.xml in your 
> reference checkout and invoke maven using -s settings.xml. Do the  
> same for your local dev checkout and make sure that the 
> <localRepository> element [1] in both is different.

LOL, Reinhard suggested the same thing earlier on in this thread.  I 
might end up trying to do it this way temporarily, if that's what it 
takes to get some work done.  The main problem with it is that because 
it's not location-dependent, it's not set-and-forget, which means it's 
not foolproof, which means that ML is guaranteed to cock it up within 
the first 24 hours (either through confusion or sheer forgetfulness) 
:-/  It's also kind of a heavy-handed kluge that goes against the 
spirit of Maven (IMHO alternative local repo locations should only be 
used for testing purposes), but that's a secondary issue...

> Maven2 is not bug-free by any means, and some of its advertised ways 
> of how it "should" work (eg dependencyManagement) simply don't. For 
> example, my experience with version properties in the root pom is that 
> the variable interpolation on artifact deployment time is buggy. 
> Perhaps this has been fixed already, if so then great but everyone 
> will need to upgrade to 2.0.5-SNAPSHOT for it to work.

Right, and I realize that Maven 2 is a work in progress.  In spite of 
that, and even though it gets harshed on by a lot of people in the Java 
world, I think the Mavenization of Cocoon will turn out to have been 
one of the best decisions for Cocoon ever.  That and the 
Springification... so 2.2 is really something to hang your hat on.  
Many thx to all you guys for all the great work.

Anyway [ahem]... Maven may not be perfect yet, but like Eric Raymond 
said, "all bugs are shallow given enough eyeballs", and there are a lot 
of eyeballs on Maven right now, so I think it will get better.

> Also, if you cram the dependencies of 100+ modules and their version 
> numbers in the root pom then this can become a management bottleneck 
> as well as this pom will need to be managed and included in the 
> release process of every module.

Yes — a pain.  I don't like centralizing this.  Anyway, w.r.t. while 
there may yet be a role for <dependencyManagement> in our build system, 
it looks to me like it does not help with the intra-project 
dependencies, because it only addresses the dependent side and not the 
installing side.  The reference [1] doesn't say anything about 
<dependencyManagement> affecting the <version> of any artifact being 
built.  It just says "anybody that uses artifact Foo, you get version 
XYZ of it".  If I'm actually building Foo though, this doesn't make it 
build version XYZ, it still builds whatever its <project/version> says.

cheers,
—ml—


Mime
View raw message