[jira] [Updated] (MNG-7360) Can't parse project that has tag in plugin configuration

["Guillaume Nodet (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MNG-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillaume Nodet updated MNG-7360:
---------------------------------
    Fix Version/s: 4.0.0-alpha-2

> Can't parse project that has <parent> tag in plugin configuration
> -----------------------------------------------------------------
>
>                 Key: MNG-7360
>                 URL: https://issues.apache.org/jira/browse/MNG-7360
>             Project: Maven
>          Issue Type: Bug
>          Components: build/consumer
>    Affects Versions: 4.0.x-candidate
>         Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT (3a06530dbce82e2054afa3cc4c81631910474bd0)
> Maven home: /usr/local/Cellar/maven-snapshot/4.0.0-alpha-1-SNAPSHOT_290/libexec
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime: /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
>            Reporter: Maarten Mulders
>            Assignee: Guillaume Nodet
>            Priority: Major
>             Fix For: 4.0.0-alpha-1, 4.0.0-alpha-2, 4.0.0
>
>         Attachments: Screenshot 2021-12-13 at 13.45.01.png
>
>
> The Apache Camel project has the following snippet in their root POM:
> {code:xml}
>                 <plugin>
>                     <groupId>org.codehaus.mojo</groupId>
>                     <artifactId>flatten-maven-plugin</artifactId>
>                     <version>1.2.5</version>
>                     <executions>
>                         <execution>
>                             <id>default-cli</id>
>                             <phase>process-resources</phase>
>                             <goals>
>                                 <goal>flatten</goal>
>                             </goals>
>                             <configuration>
>                                 <!-- snip -->
>                                 <pomElements>
>                                     <!-- snip -->
>                                     <parent>expand</parent>
>                                     <!-- snip -->
>                                 </pomElements>
>                             </configuration>
>                         </execution>
>                     </executions>
>                 </plugin>
> {code}
> With Maven 4's "Build Consumer" feature enabled, parsing this plugin definition breaks with
> {code:none}
> [INFO] BuildTimeEventSpy is registered.
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Unable to transform pom
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]   
> [ERROR]   The project (/Users/maarten/Code/open-source/camel/pom.xml) has 1 error
> [ERROR]     Unable to transform pom: Not a regular file: /Users/maarten/Code/open-source/pom.xml
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the '-e' switch
> [ERROR] Re-run Maven using the '-X' switch to enable verbose output
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> {code}
> I suspect that the {{<parent>}} tag is the culprit. It seems to me that it causes the {{ParentXMLFilter}} to think it needs to do its work. The attached screenshot shows the stacktrace that brought me to this idea. As the {{BufferingParser}} class processes its buffer of events, it encounters a situation of an "end {{parent}} tag". But that {{parent}} tag did not have child elements {{version}} and {{relativePath}} and so, it decides it needs to resolve the parent as {{../pom.xml}} against the project path ({{/Users/maarten/Code/open-source/camel/}} in my case), leading to the non-existing path of {{/Users/maarten/Code/open-source/pom.xml}}.
> I think the bug here is not that it resolves to a non-existing path (it's good to check that before actually reading the file). I think the bug is that the {{ParentXMLFilter}} is acting on the {{parent}} tag inside the plugin configuration.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)