[
http://jira.codehaus.org/browse/MNG-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98855
]
Binyan commented on MNG-2546:
-----------------------------
Jason, I see you've picked this issue up. If I can shed more light on why this
is needed or how it applies in the eclipse plug-in or specifically in the more
general building OSGi bundles case then please let me know. I missed seeing
Brian F. previous comments but it al most seems like he's talking about a new
interface a mojo would implement to get pluggeg into the super-init phase.
Similar I imagine to how spring uses its create and destroy interfaces for
beans to be hooked into the spring context's lifecycle.
I imagine that this issue might be addresses/targeted for Maven 2.1, so on a
tangential issue will it be possible to dynamically create/augment MavenProject
instances and add them to the Reactor's list before it sorts them? I ask
because I just last week started taking another crack at solving the Eclipse
PDE build issue with Maven. Basically I have written up in a Confluence page
everything that the Eclipse PDE build ant scripts do, with the intent of
replacing that with several mojos. However, PDE is not about to change and I
don't want developers maintaining build info in 2 places, so I want to have a
simple pom.xml in every plugin, feature, fragment, etc project that has a mojo
bound that will augment the MavenProject instance with data pulled from
eclipse's own project files. Utimatley I would want to do this augmentation in
the "super-init" phase.
The layout could be the following:
MyPluginProject:
- pom.xml
- features/
- com.example.foo/
- pom.xml
- ...
- plugins/
- com.example.bar/
- pom.xml
- ...
- com.example.baz/
- pom.xml
- ...
Note that the pom files in the individual features and plugins folders might
not exist if they can be dynamically created a mojos in the top level pom.
> Allow plugin executions in the "super-init" phase before reactor sorting of
> modules build order
> -----------------------------------------------------------------------------------------------
>
> Key: MNG-2546
> URL: http://jira.codehaus.org/browse/MNG-2546
> Project: Maven 2
> Issue Type: Improvement
> Components: Reactor and workspace
> Affects Versions: 2.0.4
> Reporter: Binyan
> Assignee: Jason van Zyl
> Attachments: MNG-2546-maven-core.patch
>
>
> As seen here,
> http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349.
> I also have the need to bind my maven-pde-plugin to a phase before the
> reactor sorting of project build order happens. My plugin is being developed
> to build eclipse plugins, features, fragments, update sites and products.
> Right now I can build plugins and features. However the order has to
> constantly be managed by the user taking information from the eclipse
> descriptors and adding it to the pom file. For plugin projects I can bind to
> a phase before the compile phase and dynamically analyze the eclipse plugin
> descriptors and add the necessary dependencies/resources to the MavenProject
> instance and all is well. For feature projects, I also can dynamically
> analyze the eclipse feature descriptor and add the necessary resources to the
> MavenProject instance. However, features depend on other plugins, fragments
> and features. While I can dynamicaly add the plugins, fragments and features
> to the MavenProject as dependencies they are not taken into context as the
> reactor has already computed the sorting order.
> What would be perfect is if there was a "super-init" phase that plugins could
> bind to and be executed in before the normal declared lifecycle happened.
> Therefore no matter what the lifecycle was, the "super-init" phase would be
> available. Then plugins could do things like augmenting the super-pom with
> build #'s/identifiers, dependencies, dynamic projects, etc all before maven
> gets going. That would solve the problem myself and others have as well as
> be 100% backwards compatible. This super-init phase (please pick a better
> name) would e available to reactor and non-reactor builds. A more specific
> fix would be to allow plugins to ask the reactor to reevaluate the build
> order.
--
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
