You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org> on 2008/08/10 21:05:27 UTC

[jira] Created: (MINVOKER-50) Filter all POMs that are relevant to the forked build

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


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

        

[jira] Updated: (MINVOKER-50) Filter all POMs that are relevant to the forked build

Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
     [ 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 {{@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

  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 {{@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}}
- 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 {{@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 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

        

[jira] Closed: (MINVOKER-50) Filter all POMs that are relevant to the forked build

Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MINVOKER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benjamin Bentmann closed MINVOKER-50.
-------------------------------------

         Assignee: Benjamin Bentmann
       Resolution: Fixed
    Fix Version/s: 1.3

Done in [r686481|http://svn.apache.org/viewvc?view=rev&revision=686481].

> 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 {{@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}}
> - 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