[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.html#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]
