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] >> > > ----------------- > 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>! > > > > ----------------- 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>!
