[
https://issues.apache.org/jira/browse/MINVOKER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17958310#comment-17958310
]
Olivier Lamy commented on MINVOKER-50:
--------------------------------------
This project has moved from Jira to GitHub Issues. This issue was migrated to
[apache/maven-invoker-plugin#356|https://github.com/apache/maven-invoker-plugin/issues/356].
> Filter all POMs that are relevant to the forked build
> -----------------------------------------------------
>
> Key: MINVOKER-50
> URL: https://issues.apache.org/jira/browse/MINVOKER-50
> Project: Maven Invoker Plugin (Moved to GitHub Issues)
> Issue Type: New Feature
> Affects Versions: 1.2
> Reporter: Benjamin Bentmann
> Assignee: Benjamin Bentmann
> Priority: Major
> Fix For: 1.3
>
>
> Imagine a multi module project:
> {noformat}
> mod2-parent/
> mod1/
> pom.xml
> mod1-parent/
> pom.xml
> mod2/
> pom.xml
> pom.xml (aggregator of mod1 and mod2)
> {noformat}
> When the Invoker Plugin is configured to run the build on
> {{mod2-parent/pom.xml}}, i.e. do a reactor build, none of the POMs in the sub
> directories are filtered, only the reactor root POM is. This makes it hard
> for those POMs to reference the artifact under test via {{@pom.version@}} or
> similar. Possible workaround is using system properties but this is
> cumbersome.
> My initial assumption is we could analyze the executed POM's model and
> recursively follow modules/parents to locate the other POMs that will
> participate in the invoked reactor build to filter these, too. This in turn
> would require to
> - either rewrite all models to reference the {{interpolated-pom.xml}} (would
> require Maven 2.0.9+, see MNG-1493)
> - or simply retain the original file name of the POM which is of couse only
> possible when cloning the projects
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
