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] > ----------------- Come read my webnovel, Take a Lemon <http://www.takealemon.com>, and listen to the Misfile radio play <http://www.gold-family.us/audio/misfile.html>!
