maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dawid Weiss (JIRA)" <j...@apache.org>
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

    [ https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16104866#comment-16104866
] 

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:

{noformat}
> d:
{noformat}

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):

{noformat}
> D:
{noformat}

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:
{code}
[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)
{code}

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}}:

{code}
                /*
                 * 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 );
                    }
                }
{code}

Looks innocent, but those location URIs on Windows give me a false positive on the drive letter,
for example:
{code}
file:/d:/_tmp/repro/lingo4g-public/pom.xml 
file:/D:/_tmp/repro/lingo4g-public/pom.xml
{code}

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: https://issues.apache.org/jira/browse/MNG-6261
>             Project: Maven
>          Issue Type: Bug
>    Affects Versions: 3.5.0
>            Reporter: Dawid Weiss
>            Priority: Minor
>         Attachments: capture-6.png, repro.zip
>
>
> 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
(v6.4.14#64029)

Mime
View raw message