On 28 May 2013 20:22, Baptiste MATHUS <[email protected]> wrote: > 2013/5/28 Mike Wilson <[email protected]> > > > > Is this what you are seeing? > > > > Sort of. But it seems you have assigned relativePath to a non- > > empty value, something I think is incorrect in this kind of > > setup. > > I believe my setup was described in enough detail in my > > previous post. I used no relativePath elements. > > > > > The non-resolvable parent POM error, I believe is due to the > > > reactor attempts to determine the processing order. > > > > I see no reason why Maven cannot locate all aggregated modules > > first using the reactor, and resolve parent+dependencies in > > the next phase. Then this is a non-issue. > > I believe this is how Maven 2 works. > > > > > Your case (3) is not following any accepted pattern that > > > Maven supports. > > > > It seems this was an accepted pattern in Maven 2 but not in > > Maven 3. Or are you saying this was not an accepted pattern in > > Maven 2 either, and worked by fluke? > > > > Didn't dig on that very subject, but IIRC, kind of. Parent pom could > sometime be downloaded although it *was* part of the reactor. > Being more explicit and less permissive is one of the features of m3 (as is > the build reproducibility for maven in general). > > IIRC another issue was that if the "parent" from the reactor has a different version from the parent specified in the pom, Maven 2.x just uses the one from the reactor while with this fix Maven 3.x will correctly attempt to download and use the specified version from the remote reposotory / local cache
I have not tested if this change allows Maven 3 to have two different versions of the same GA within the one reactor... but irrespective of that issue it does allow the parent version to be disconnected from the version picked up by "child" poms
