Yes, I've also found that I have to "mvn install -N" on the first build of a parent (when it does not exist in local or remote repo) otherwise the build fails. If that is what you are experiencing, then me too. I've never looked further, as it happens so infrequently.
On Mon, Aug 22, 2011 at 10:38 AM, Laird Nelson <[email protected]> wrote: > On Mon, Aug 22, 2011 at 11:22 AM, Benson Margulies <[email protected] > >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 >
