cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans <jheym...@apache.org>
Subject Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Date Sat, 27 Jan 2007 14:39:02 GMT
Mark Lundquist wrote:

> LOL, Reinhard suggested the same thing earlier on in this thread.  I 

ah true i see that now, sorry !

> 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) 

true, but that's how it is. Anyway I'm sure you can batch-script your 
way around this.

> :-/  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.

well that's what you were describing no? Keeping trunk for testing 
purposes and a local build to tinker with without impacting the other?

> 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.

eventually yes. But for such a high profile project it surprises me that 
their last release is dated almost a year now.

>> 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.

Yes dependencyMgmt is all about managing the dependencies of your 
project, not the artifacts it produces. Note that its usage is currently 
discouraged as it doesn't really work as advertised. I think it was 
scheduled to be fixed for 2.0.5, then pushed to 2.0.6 ...

Thanks for your interesting thoughts!


Jorg


Mime
View raw message