[
http://jira.codehaus.org/browse/MECLIPSE-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156178#action_156178
]
Benjamin Bentmann commented on MECLIPSE-414:
--------------------------------------------
bq. Isn't that only if the CLI plugin isn't part of the normal lifecycle?
I don't fully get the meaning of those words. A plugin goal is either executed
directly from the CLI, i.e. via "mvn <prefix>:<goal>", or indirectly from some
lifecycle, i.e. via "mvn <phase>" in combination with an {{<execution>}} from
the POM. That is to say, direct invocations from CLI are considered standalone
goal executions and are never part of any lifecycle.
bq. In this case m-eclipse-p is bound to the @phase generate-resources
What case exactly do you refer to? In the plugin's source code, i.e.
{{EclipsePlugin.java}}, I merely see [EMAIL PROTECTED]
phase="generate-resources"}} which has an entirely different semantic than the
similar looking [EMAIL PROTECTED] generate-resources}}. The first annotation
requests a forked execution, while the second annotations defines a default
phase if the goal is specified in an {{<execution>}} for which the user omitted
the {{<phase>}} element.
I mean for the case of executing "mvn eclipse:eclipse", the eclipse goal is not
bound to any lifecycle phase. No lifecycle phase, no other plugins unless the
goal explicitly requests a forked lifecylce/goal execution. That is why the
{{project}} variable does not see sources/resources that get dynamically
created/registered by other goals during the lifecycle.
Maybe that simplified flow can shed some light on this:
# "mvn eclipse:eclipse" is invoked by user
# {{MavenProject}} instance is build from POM, call this instance A
# lifecycle phase "generate-resources" is forked as per the eclipse goal's
[EMAIL PROTECTED] annotation
## {{MavenProject}} instance is build by cloning instance A, call this instance
B
## the lifecycle bound plugins are called, where their parameter expression
{{${project\}}} resolves to instance B, i.e. the plugins update instance B with
generated sources/resources
# Finally, the eclipse goal itself is executed, where {{${project}}} is
resolved with instance A and {{${executionProject}}} is resolved with instance B
If you like, have a look at {{DefaultLifecycleExecutor}} from the module
maven-core, that's where most of this process is handled.
> Not beeing @aggregator, eclipse plugin does not require executedProject
> -----------------------------------------------------------------------
>
> Key: MECLIPSE-414
> URL: http://jira.codehaus.org/browse/MECLIPSE-414
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Affects Versions: 2.5
> Reporter: nicolas de loof
> Assignee: Barrie Treloar
> Fix For: 2.6
>
>
> The eclispe plugin uses both ${executedProject} and ${project}.
> Not beeing an aggregator plugin, ${project} is allways tghe currently
> executed project, and the projectDirectory is project.getBasedir().
> Having two attributes for same target makes the plugin harder to understand
--
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
