[ http://jira.codehaus.org/browse/MNG-2546?page=comments#action_74195 ] Binyan commented on MNG-2546: -----------------------------
I'm saying (I think) that maven should have 1 LifecycleExecutor whose job is to execute a single Lifecycle. The lifecycle to execute could be specified on the command line and/or in the pom. I'm mainly thinking about multi-project builds but I don't see big benefits for single projects at my current caffiene level. If the user did NOT specify a lifecycle on the command line or in the pom, then the lifecycle executor would execute a new "default" lifecycle the same as it does today. The default lifecycle would have the pre and post reactor phases you previously outlined. The LifecycleExecutor would execute the lifecycle from start to designated phase as it does today. The big switch IMO is that the reactor would be a plugin that is bound to the reactor phases and would be called to execute the reactor across the current default lifecycle (validate ... deploy). This would allow binding before and after the reactor and current projects would continue to work with out any changes. I'm thinking we need this Lifecycle Name: Phases/Component Lifecycles ================================================================= Pre-Reactor Lifecycle: reactor-init, reactor-start Reactor Lifecycle: reactor-build Post-Reactor Lifecycle: reactor-stop, reactor-assemble, reactor-verify, reactor-stop Default Lifecycle: Pre-Reactor Lifecycle, Reactor Lifecycle, Post-Reactor Lifecycle Foo Lifecycle: clean-room-phase, take-out-trash-phase, Default Lifecycle, brush-teeth-phase The default lifecycle would be composed of the "Pre-Reactor, Reactor, and Post-Reactor" lifecycles. This is why I thought of the composition pattern because a lifecycle is composed of phases and other lifecycles as components. Now you could bind the assembly plugin to a phase in the pre-reactor lifecycle or you could declare your own lifecycle,like the Foo lifecycle, which declares it's own phases with plugin bindings and a component lifecycle, (i.e. Default lifecycle). Was this any clearer? > 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 > 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
