Same use case for me.
Most of the time users work on single module. But we also create artificially (using svn:externals) big multimodule builds with an aggregator pom. This is to allow a full clean build on CI platform. relativePath is set to empty in order to avoid maven complains when working on a single component. So in our big build we have A, B and C in this order where B is parent of A and C. Doing mvn clean install, A will get old parent from repo (when available) while C will get newest parent that was installed just before. I feel reordering reactor by taking parent relationship into account can solve this issue. Regards Julien ----- Mail original ----- > De : Laird Nelson <ljnel...@gmail.com> > À : Maven Users List <users@maven.apache.org> > Cc : > Envoyé le : Lundi 22 Août 2011 17h38 > Objet : Re: Reactor doesn't build parent poms first? > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
