[ http://jira.codehaus.org/browse/MNG-2546?page=comments#action_74188 ] John Casey commented on MNG-2546: ---------------------------------
Wanted to link in this conversation, and also add a comment (somewhat excerpted from the mail thread). The thread is here: http://www.nabble.com/forum/ViewPost.jtp?post=6141419&framed=y And my comment is: I think we should explore design/development of a reactor-level lifecycle which will run once and only once per maven invocation (per build, not per project). This would allow us to declare some discrete phases in which different categories of reactor-level work takes place, and align plugins to those phases so that a more-or-less declarative ordering at the reactor level can be achieved. In this model, the module builds would take place in a reactor phase somewhere in the middle of the reactor lifecycle, allowing us to bind plugins for a single run before or after the modules are built, or even before or after other reactor-level plugins. It would also replace the current @aggregator syntax for mojos, I think, since you would have more control over that mojo's placement than simply saying, "Run only once; I don't care when." The lifecycle/phase pattern works relatively well right now for single-project builds, and for most builds in a given reactor scenario. I think repeating the pattern at the reactor scale would allow us to address reactor-level and project-level plugin binding design changes at the same time, if/when we decide to do that for future releases. Please see the email thread for more detail on this proposal. > 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
