Details
-
Wish
-
Status: Closed
-
Major
-
Resolution: Incomplete
-
3.0
-
None
-
None
Description
The assumption that project modules always are independent does just not hold true. In many cases, modules (especially those in a reactor build) are separated in order to isolate dependencies (in-going or out-going). Such modules are often tightly coupled and one does not want to 'install' or 'deploy' one of them unless all of them are install-/deployable and installed/deployed at the same time (for instance mentioned here: http://in.relation.to/12116.lace ). That means: there should be a way to compile all modules against each other and test all modules (against each other) before any of the modules are installed/deployed.
This calls for an option (which should be default from 4.0 ...) to do breadth-first reactor builds: Instead of running the entire lifecycle per project module, each lifecycle step should be run for all modules before proceeding with the next. The run-time project setup must also be configured to use the target/classes and target/test-classes (etcetera) directories of the depending modules rather than the repository artifact for modules in the reactor. This will cause the install and deploy phases to come after the test phases, making sure nothing is deployed unless all modules work and fit together.
In my experience (we hacked this with maven 1.0), this also provide faster feedback for multi-module enterprise projects with high velocity, where improper refactorings in shared modules often is the cause of compile-time errors downstream. Given that real-life reactor builds easily take 15-20 minutes, catching compile-time errors before wasting time on tests catches all the "stupid mistakes" about 5 times faster (assuming test runs consume roughly 80% of the build time).