[
http://jira.codehaus.org/browse/MINVOKER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MINVOKER-50:
--------------------------------------
Description:
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 [EMAIL PROTECTED]@}} 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
was:
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 [EMAIL PROTECTED]@}} 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}}
- or simply retain the original file name of the POM which is of couse only
possible when cloning the projects
> Filter all POMs that are relevant to the forked build
> -----------------------------------------------------
>
> Key: MINVOKER-50
> URL: http://jira.codehaus.org/browse/MINVOKER-50
> Project: Maven 2.x Invoker Plugin
> Issue Type: New Feature
> Affects Versions: 1.2
> Reporter: Benjamin Bentmann
> Assignee: Benjamin Bentmann
> 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 [EMAIL PROTECTED]@}}
> 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 is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
