On Mon, Aug 22, 2011 at 11:22 AM, Benson Margulies <bimargul...@gmail.com>wrote:
> I'm foggy on one point here. How can the pom in the reactor differ > from the pom reached by relative path? Different property > substitutions? Or is the issue here the case in which there is no rel > path, but it is in the reactor? > (I'll quickly chime in with my background use case--or at least the reason why I brought up all this stuff initially.) In my organization we have lots of modules. Developers typically only work on a given module at a time. We've set things up in a pretty standard fashion so that they can check that module out and work on it without having to check out the other modules. We've got Nexus proxying various repositories; all artifacts that are depended upon basically get downloaded through that. Standard Maven stuff. Of course, the developers often do have the whole project checked out. That used to cause some weird problems, detailed below. Some of our modules have parents that are other modules. So we have a standard -pomtypes-jpa module, for example, that does some stuff in its <build> section to do things like generate the list of entity classes that should be included in a persistence.xml during unit/integration testing. Other modules may extend this as their parent to pick up this behavior. Occasionally, we need to make changes to these mid-level modules. Back in the day, we had a bunch of relativePath elements. But developers were getting confused, because if they were working on a JPA module that inherited from this -pomtypes-jpa module, then if they hadn't version-control-updated their -pomtypes-jpa module, the relativePath element would kick in and try to use the working copy in their workspace. Oops. The solution in this case was: if you have the -pomtypes-jpa module checked out, make sure you svn update it religiously so that when relativePath finds it, you're getting the most recent copy from Subversion. OK, fine, so we finally decided, forget this, the relativePath element is kind of a hack anyway (or at least didn't fit our needs at all). So now all pom resolution comes from the repository. That's cool; that's like every other Maven artifact. Smooth sailing. We update the -pomtypes-jpa pom.xml, and all children who extend it pick it up automatically (we're still in SNAPSHOT mode). However, this is kind of odd when we're doing a full build. Suppose one of these developers hasn't done a full build in ages and ages. Or, for that matter, hasn't worked on a JPA module, so hasn't caused Maven to go look for a new SNAPSHOT version of that -pomtypes-jpa project. Now, when we execute that full build right after a global svn update, the full build will go use the (comparatively ancient) 1.0-SNAPSHOT version of -pomtypes-jpa's pom.xml from the local repository (or the remote), which is, of course, the most recent *deployed* version, but might very well not be the most recent version *in Subversion* that they just checked out to their workspace. Really since we're doing a full build, we'd like it to use...well, the one that should be built right now. :-) We would like it to realize that one of the artifacts that a module extends from is actually *in the build plan currently being executed*, so gee, it would be nice if Maven would sort it all the way up in the topologically sorted list of reactor projects. Obviously it could potentially affect property substitution and the like for child poms, so you'd want to make sure this thing was built first. Maybe that's all backwards and wrong-headed, but it's where I was coming from. One "customer"'s input. The workaround for us is to wrap Maven so that we do mvn -o clean install on the parent poms first, in topological order, then run mvn clean install from the root. I was looking for this sort of thing to be handled natively by the reactor. Best, Laird -- http://about.me/lairdnelson
