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â
