cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans <>
Subject Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Date Thu, 25 Jan 2007 19:46:30 GMT
Mark Lundquist wrote:
> What I'm trying to have is (a) a "reference" build of trunk that does 
> not have any of my local fingerprints on it, and (b) a local development 
> build (or even, potentially, more than one of those).  Then I can play 

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.

> Each lower-level pom would use the appropriate ${cocoon.verision...} 
> property in setting its <version>, and would similarly use these 
> properties to define <version>s of its <dependency>s.  If e.g. trunk 
> development requires, say, that some level have a different version 
> number, then it would be changed at that level in the root pom's tree of 
> version property definitions.  (I'm talking about controlled changes in 
> Subversion here, not local changes).  (Note, there would be no more need 
> for the pom-updater in this scheme).


> Now, this breaks good design because the root pom has to know details 
> about the whole project tree, which countervails decomposition by 
> hierarchal project aggregation.  But... it does allow me to have 

"countervailing decomposition by hierarchical project aggregation", mind 
if i use that one in my next presentation to senior management? :P

> multiple builds that can coexist because they do not create artifact 
> clashes in my local maven repo, because I can trigger a build profile 
> that overrides whichever version properties I require to be unique for 
> that build.

Mark, i think you have a lot of great ideas about improving our build. 
At this point i cannot say whether any of them will fully work, you 
should just try it out a bit and report back.

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



View raw message