[jira] Updated: (MNG-2581) Mojo's with @execute don't get configured with executedProject

["Benjamin Bentmann (JIRA)" <ji...@codehaus.org>]

     [ http://jira.codehaus.org/browse/MNG-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benjamin Bentmann updated MNG-2581:
-----------------------------------

    Fix Version/s:     (was: 3.0-alpha-8)
                   3.x (to be reviewed)

The issue here is that we have no mojo annotation to express a mojo's prerequisite on a certain lifecycle phase for its proper execution. As a workaround, plugin authors forked the lifecycle to ensure the required build state/output is present but forking just doesn't fit this use case.

> Mojo's with @execute don't get configured with executedProject
> --------------------------------------------------------------
>
>                 Key: MNG-2581
>                 URL: http://jira.codehaus.org/browse/MNG-2581
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Plugins and Lifecycle
>            Reporter: Kenney Westerhof
>             Fix For: 3.x (to be reviewed)
>
>
> Not sure if this is a bug or an improvement, but here's a scenario:
> A custom plugin defines a MavenProject property with a timestamp. That timestamp
> is used in <finalName>${project.artifactId}-${timestamp}</finalName>.
> During the normal plugin execution, this field is evaluated correctly.
> When running mvn assembly:assembly, the normal (forked) lifecycle also functions correctly.
> But the assembly Mojo is configured with the original MavenProject, that doesn't have the ${timestamp} property,
> so the <finalName> parameter on the assembly mojo will be "someArtifact-null".
> A tough problem, but it goes further: Ideally you never want to use ${project} as a parameter, but
> the objects fields directly. Say you want to use the source roots and define that as a parameter. Then you
> never get access the generated-sources unless you manually examine the executedProject.
> Right now, mojo's have to use different logic depending on whether they specify @execute phase="X",
> (and examine fields of the executedProject).
> Can we drop the original MavenProject object and replace that with executedProject instance, so we only have
> 1 instance of MavenProject? 
> Or, if there are plugins that MUST use the original MavenProject, or use both MavenProject instances (we might
> want to scan all existing mojo's to see what they do), can we add
> a plugin flag that specifies that that mojo must be configured using the executedProject instead?

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