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).
sure.
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.
Regards Jorg [1] http://maven.apache.org/settings.html
