[ https://jira.codehaus.org/browse/MNG-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Osipov updated MNG-2581: -------------------------------- Fix Version/s: (was: 3.x / Backlog) > Mojo's with @execute don't get configured with executedProject > -------------------------------------------------------------- > > Key: MNG-2581 > URL: https://jira.codehaus.org/browse/MNG-2581 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle > Reporter: Kenney Westerhof > > 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 was sent by Atlassian JIRA (v6.1.6#6162)