On 9 December 2014 at 10:29, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote:
> On 9 December 2014 at 10:16, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> Added this to >> https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 >> > > So I am now thinking that you would achieve this by doing something along > the lines of: > > * Mojos can declare that the contribute to "targets" such as the > target/classes or target/test-classes directories > > This lets Maven find the last phases that contribute to a "target" and > escalate the module up to those phases when a different module has a > dependency on a "target" > > * Mojos can declare that a "target" can be used as a substitute for a > packaging, so for example the java compiler can use target/classes in place > of the .jar artifact, while the dependency:copy mojo would have a hard > dependency > > * Phases can declare constraints on other phases, such as happens after > and finally. > > - If we keep the site lifecycle, then initialize would happen before > pre-site. The site:site mojo would then require different "targets" as a > result of the reports it is configured with, so the javadoc report requires > a completed target/generated-sources target which will pull in the > process-sources phase as there is a plugin bound to that phase that > contributes to target/generated-sources. Similarly the surefire report > requires a completed target/surefire-reports target which will pull in the > test phase. > - IOW we would enhance the AbstractMojo class so that there was a method > that allowed the mojo to return a list of requirements. That would allow > Maven 3 plugins to work as before in a legacy mode, while Maven 4 plugins > would give the enhanced smart reactor behaviour > Hmmm, thinking further, this could enable removing the special case of site plugins If reporting plugins declare as contributing to target/site and site:site declares as finalize target/site and site:site-deploy declares as consuming target/site Then we can effectively move plugins out of the build section and just put it directly in the pom as a top level element. The site behaviour would just "fall out" of plugins declaring that they contribute to / finalize / consume various "targets" The lifecycle becomes a way to bind plugin executions to phases, plugin executions declare targets that the contribute / finalize / consume and we can construct the minimal build plan from the users request. It does make reasoning about what a specific user request will do a bit harder for users to understand, but on the other hand it should make their actual experience easier. > >> On 9 December 2014 at 08:31, Stephen Connolly < >> stephen.alan.conno...@gmail.com> wrote: >> >>> So if I have a multi-module reactor... >>> >>> There's a jar module, a war module and a module for integration tests on >>> the war module. >>> >>> When I type `mvn4 test` should the reactor be smarter? >>> >>> It sees the need to run up to the test phase on all modules, and it sees >>> that the integration tests module has a dependency on the war artifact... >>> >>> Then the packaging4 of war artifacts says the war dependency is produced >>> by the `package` phase, so the build plan is upped to package for the war >>> module >>> >>> The war module has a dependency on the jar module when packaging (the >>> test phase can work with the classes directory in the war module) so the >>> jar module is bumped to package as well >>> >>> Net result is that `mvn4 test` will work without having to populate the >>> remote repo or local cache. >>> >>> Thoughts? >>> >>> I know it makes things more complex and involves enhancing the packaging >>> descriptors... But I think this is what people expect >>> >>> >>> >>> -- >>> Sent from my phone >>> >> >> >
