maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Gold <>
Subject Re: maven 3 doesn't use reactor to find parent - revert to maven 2 behaviour
Date Thu, 23 May 2013 15:46:41 GMT
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 <> 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]
> patibilityNotes-ParentPOMResolution
> [2]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Come read my webnovel, Take a Lemon <>, 
and listen to the Misfile radio play <>!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message