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 <mike...@hotmail.com> 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 <mike...@hotmail.com> 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 >> <mike...@hotmail.com> 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: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > ----------------- 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>!
