maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dawid Weiss (JIRA)" <>
Subject [jira] [Commented] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
Date Fri, 28 Jul 2017 12:12:00 GMT


Dawid Weiss commented on MNG-6261:

And I now know where the problem is. Try this, Robert: open up cmd and switch to another drive:

> d:

Note the drive's path should be case-sensitive (so lowercase in this example). I don't know
how or why Windows does it, but if you type (the first time):

> D:

it'll be upper-case cwd. Now, try to run 'mvn validate' on the project I attached as the repro.
In one of these windows the build will succeed, in the other it'll fail.

The problem was fairly easy from there on. I noticed that the failing build attempts to resolve
certain POMs that should have been in the build's reactor:
[DEBUG] Could not find metadata com.carrotsearch.lingo4g:lingo4g-public:1.6.0-SNAPSHOT/maven-metadata.xml
in local (E:\bamboo-home-3\.m2\AGENT-2752517\repository)

this was odd (and not present in the successfull build). So I dug down and dumped some stack
traces to see how this happens. Turns out the problem is this fragment in {{DefaultModelBuilder}}:

                 * NOTE: This is a sanity check of the cache hit. If the cached parent POM
was locally resolved, the
                 * child's <relativePath> should point at that parent, too. If it doesn't,
we ignore the cache and
                 * resolve externally, to mimic the behavior if the cache didn't exist in
the first place. Otherwise,
                 * the cache would obscure a bad POM.

                File pomFile = parentData.getModel().getPomFile();
                if ( pomFile != null )
                    ModelSource expectedParentSource = getParentPomFile( childModel, childSource

                    if ( expectedParentSource instanceof ModelSource2
                        && !pomFile.toURI().equals( ( (ModelSource2) expectedParentSource
).getLocationURI() ) )
                        parentData = readParentExternally( childModel, request, problems );

Looks innocent, but those location URIs on Windows give me a false positive on the drive letter,
for example:

One of these is relative and is resolved using {{getAbsoluteFile}} which (I believe, didn't
check) uses an upper-case drive letter. The other is resolved based on the cwd.

The ideal solution and fix for this would be to use NIO2's utilities ({{Files.isSameFile}}
for comparing {{Path}} instances. The filesystem provider knows whether the filesystem is
case sensitive or not. But even with {{File}} instances resolving canonical File instances
and using {{File.compareTo(File)}} would be a better solution than comparing URIs.

A patch here is trivial (although exact solution is probably dependent on the variant chosen,
as I mentioned), so I don't include a patch.

> Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
> -------------------------------------------------------------------------------
>                 Key: MNG-6261
>                 URL:
>             Project: Maven
>          Issue Type: Bug
>    Affects Versions: 3.5.0
>            Reporter: Dawid Weiss
>            Priority: Minor
>         Attachments: capture-6.png,
> In my effort to upgrade an existing (fairly complex) Maven build to Java 1.9.0 I updated
Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]:
Could not find artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and 'parent.relativePath'
points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex -- the
submodule hierarchy is not aligned with parent-child pom hierarchy (it's best to look at the
repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I wonder if it's
a regression bug or maybe underspecified Maven requirement (that should be enforced with a
warning and not lead to this odd runtime message).

This message was sent by Atlassian JIRA

View raw message