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 > 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 >> > >
