[ http://jira.codehaus.org/browse/MNG-2546?page=comments#action_74192 ] John Casey commented on MNG-2546: ---------------------------------
I'm not sure I follow; are you saying that we should collapse the reactor phases into the main project build lifecycle as a new version of the existing default, and then selectively execute part of that lifecycle outside the reactor, and other parts within the reactor (i.e. per-project)? The reason I like the concept of scoped lifecycles is that any existing project today, when released, may have a need to produce a binary assembly that contains all of the module projects, etc. If we wrap the existing (or any other) lifecycle inside a reactor-level lifecycle, then these people will have the ability to bind the assembly plugin outside of the project-level lifecycle and have it execute at the appropriate time. IMO, the semantics of binding to a project-level lifecycle (for war, ear, ejb, etc. packaging) shouldn't change in most cases with this addition. However, now that I think a little more about your use cases (eclipse plugin dev), I think I see what you're getting at. You'd like to be able to specify something akin to <packaging>war</packaging> and have the reactor-level lifecycle bindings be provided by the default mapping for the packaging. We already have three lifecycles used in Maven, and a given packaging can choose to override any of the three. They are: clean, site, and default. The default one is for "normal" builds, and the other two are pretty self-explanatory, I guess. What if we added another lifecycle called "reactor" or "multimodule" which would allow mapping of things like your pde pre-processor mojo when the packaging == pde-plugin or similar? If you want to see how these are constructed, have a look at: http://svn.apache.org/repos/asf/maven/components/trunk/maven-core/src/main/resources/META-INF/plexus/components.xml and search for 'DefaultLifecycleMapping' to see how the different packaging types are mapped in. Would this meet your requirements? > 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
