> 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? As you suggested previously I will bring this subject to the dev list, see post "parent pom lookup in reactor". Best regards Mike Russell Gold wrote: > OK, I think I have managed to duplicate the behavior. Is this > what you are seeing? > > > [ERROR] > > [ERROR] The project com.packtpub.maven:obfuscate:1.0 > (/Users/russgold/projects/maven-course/sample4/obfuscator/pom. > xml) has 1 error > > [ERROR] Non-resolvable parent POM: Could not find > artifact com.packtpub.maven:parent4:pom:1.0 in central > (http://repo.maven.apache.org/maven2) and > 'parent.relativePath' points at wrong local POM @ line 5, > column 13 -> [Help 2] > > The non-resolvable parent POM error, I believe is due to the > reactor attempts to determine the processing order. It reads > each pom to see what its dependencies are - but part of those > dependencies could themselves be defined in the parent, so it > needs to be able to resolve the parent as part of this process. > > If you use the conventional pattern in which a parent > aggregates its children, then the reactor already knows the > parent. If you don't, unless the parent is already in the > repository, it has no way of knowing what the parent is in > order to determine the proper build order. It may be that in > Maven 2, this determination was not done, and the module > order specified by the aggregator was followed blindly. > > Your case (3) is not following any accepted pattern that > Maven supports. It is often said, "if you fight with Maven, > you will lose." > > > On May 27, 2013, at 12:01 PM, Russell Gold > <[email protected]> wrote: > > > I'm having trouble understanding your use case still, I > think - and you are disregarding the general pattern that > child poms are found nested under their parent; however, from > your description, I don't see why this wouldn't work. Can you > make a small sample project that displays the problematic > behavior and post it somewhere? > > > > On May 24, 2013, at 10:07 AM, Mike Wilson > <[email protected]> wrote: > > > >> There are many variations, but here is a simplification of our > >> own scenario: > >> > >> 1) Consider a number of standalone modules with their own > >> release cycles in their own VCS repos: > >> parent/ [vcs0] > >> pom.xml (1.0.0) > >> module1/ [vcs1] > >> pom.xml (1.1.0, parent=parent-1.0.0) > >> module2/ [vcs2] > >> ... > >> > >> 2) Team 1 is updating module1 in feature branch f1: > >> module1/ [vcs1] > >> pom.xml (1.2.0-f1-SNAPSHOT, parent=parent-1.0.0) > >> They want to refer to the pre-built released parent from repo. > >> > >> 3) Team 2 is updating module1 and the parent in feature > >> branch f2. They have aggregated all modules they are > >> working on in a feature workspace pom for easy building: > >> feature2workspace/ [aggregation root] > >> pom.xml (modules=parent,module1) > >> parent/ [vcs0] > >> pom.xml (1.1.0-f2-SNAPSHOT) > >> module1/ [vcs1] > >> pom.xml (1.2.0-f2-SNAPSHOT, parent=parent-1.1.0-f2-SNAPSHOT) > >> They want to refer to the local checkout of parent. > >> > >> As you can see, module1 can not make any assumption about > >> what filesystem directory the parent module resides in, so no > >> relativePath element can be added. > >> In Maven 2 there is success when building the feature workspace > >> from root, but Maven 3 fails. > >> > >> To get it working in Maven 3 we either have to maintain > >> relativePath elements that are different for every feature-branch > >> (and deal with them when merging back into main = error-prone), > >> or manually have to deal with build order within the feature > >> workspace. > >> > >> In reality our case is made up of hundreds of standalone modules > >> and parent/sub-repos used for the aggregation level, representing > >> a feature or team branch where the root pom.xml is thus > >> shared between team members through the parent repo. > >> > >> Best regards > >> Mike > >> > >> Russell Gold wrote: > >>> Only the developers could say for sure, but I would guess > >>> that it was done as part of code cleanup - that it's not so > >>> much that they wanted to remove the feature as it was that > >>> cleaning up the code might have made it hard to support the > >>> feature - and there was no particular reason to keep it. But > >>> that's just a guess. I am not on the development team and > >>> haven't studied the code changes. > >>> > >>> So I'll ask more specifically. Why do you think such a use > >>> case is needed? Under what conditions would a parent be part > >>> of a project and yet its location could not be known to the > >>> rest of the project? > >>> > >>> Regards, > >>> Russ > >>> > >>> On May 23, 2013, at 5:05 PM, Mike Wilson > <[email protected]> wrote: > >>> > >>>> I'm trying to make the point that Maven 2 had the expected > >>>> behaviour, and Maven 3 changed that into something less > >>>> good. As far as I can read the motivation, it seems to have > >>>> been done for the wrong reason. > >>>> > >>>> But it's quite likely I'm missing something, and that a > >>>> better motivation may be found outside the compatibility > >>>> notes. > >>>> > >>>> So, what is the main advantage with having Maven not look > >>>> for parent modules in the reactor list? > >>>> Is there any advantage [for the user] at all? > >>>> > >>>> Best regards > >>>> Mike > >>>> > >>>> [I'm posting to the users list to avoid disturbing the dev > >>>> list in case I've missed something obvious] > >>>> > >>>> Russell Gold wrote: > >>>>> I'd think this would be better suited for the maven > >>> developers list. > >>>>> > >>>>> But it seems to me that in the case where modules are not > >>>>> supposed to know where their parents are located, the working > >>>>> assumption is that the parent is already in the repo and > >>>>> built separately. > >>>>> > >>>>> That is, there are two cases: > >>>>> 1) Parent is part of the project. In this case, it is more > >>>>> than reasonable for the modules to use the relative-path > >>>>> mechanism to find their parents. > >>>>> 2) Parent is independent of the project. In this case, the > >>>>> parent should already be in the repo before doing a build > >>>>> which includes the modules. > >>>>> > >>>>> I don't understand your use case, which appears to be neither > >>>>> of these. > >>>>> > >>>>> On May 23, 2013, at 9:20 AM, Mike Wilson > >>> <[email protected]> wrote: > >>>>> > >>>>>> [Note: this entire post deals with project layouts where it is > >>>>>> undesired for modules to know in what filesystem > directory their > >>>>>> parent module resides. This rules out relying on Maven parent > >>>>>> found in parent directory or through the relativePath element.] > >>>>>> > >>>>>> Maven 3 will throw a "Non-resolvable parent POM" error > the first > >>>>>> time this project layout is built, even when built from the > >>>>>> aggregation root: > >>>>>> app/ > >>>>>> pom.xml (modules=parent,submodule) > >>>>>> parent/ > >>>>>> pom.xml > >>>>>> submodule/ > >>>>>> pom.xml (parent=parent) > >>>>>> > >>>>>> Maven 2 will succeed, as it is using the reactor to > locate parent > >>>>>> modules in the local checkout, just as is done for > dependencies. > >>>>>> > >>>>>> Maven 3 on purpose no longer uses the reactor for parents, but > >>>>>> still uses it for dependencies. The motivation can be studied > >>>>>> in [1] but boils down to that modules that build > successfully as > >>>>>> part of a reactor build, could fail when built by > itself without > >>>>>> having manually built the parent first, so it is > better to always > >>>>>> fail. > >>>>>> > >>>>>> Thus, in summary when a module refers to a dependency or parent > >>>>>> within the local checkout, we will see this behaviour: > >>>>>> ----------------------------------------------------------- > >>>>>> MAVEN 2 referral type dependency parent > >>>>>> build type reactor single reactor single > >>>>>> ------- ------- ------- ------- > >>>>>> referred not in repo SUCCESS FAIL SUCCESS FAIL > >>>>>> referred already in repo SUCCESS SUCCESS SUCCESS SUCCESS > >>>>>> ----------------------------------------------------------- > >>>>>> MAVEN 3 referral type dependency parent > >>>>>> build type reactor single reactor single > >>>>>> ------- ------- ------- ------- > >>>>>> referred not in repo SUCCESS FAIL FAIL FAIL > >>>>>> referred already in repo SUCCESS SUCCESS SUCCESS SUCCESS > >>>>>> ----------------------------------------------------------- > >>>>>> > >>>>>> I question this judgement, because: > >>>>>> > >>>>>> a) It violates the principle of least surprise [2], as a module > >>>>>> taking part in the reactor build is left out of some module > >>>>>> resolutions (parent) but included in some (dependencies). > >>>>>> > >>>>>> b) The reasoning in [1] is either wrong, or only halfway done, > >>>>>> depending on how you see it. > >>>>>> The motivation given is to avoid different outcome for reactor > >>>>>> and single module builds. But the difference in outcome still > >>>>>> exists wrt dependencies and this violates both the given > >>>>>> motivation and [2]. > >>>>>> So, to fulfill the goal, the same behaviour should be enforced > >>>>>> for dependencies, ie failing aggregator builds when > dependencies > >>>>>> only exist in the local checkout. > >>>>>> That would create a consistent experience but would of > course be > >>>>>> undoable. > >>>>>> > >>>>>> c) For a number of project layouts the Maven 3 > behaviour forces > >>>>>> the developer (or Jenkins setups etc) to manually handle the > >>>>>> build order of artefacts within a Maven aggregation, something > >>>>>> that Maven normally should take care of. > >>>>>> > >>>>>> I propose to revert to the Maven 2 behaviour in this respect. > >>>>>> > >>>>>> Thanks > >>>>>> Mike Wilson > >>>>>> > >>>>>> [1] > >>>>>> > >>>>> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.ht > >>>>> ml#Maven3.xCom > >>>>>> patibilityNotes-ParentPOMResolution > >>>>>> > >>>>>> [2] > http://en.wikipedia.org/wiki/Principle_of_least_astonishment --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
