Kristian Rosenvold wrote:
I will re-add your stuff, and I will also set it up to use my output
demultiplexer that causes output to appear in "normal" order.
Does the demultiplexer do anything in weave mode when threads=1? Does it
make the projects appear to unweave (as far as the log is concerned)?
Which brings me to another high-level concern here;
All I *really* want/need is to run test in the exact manner you are
describing. In reality I'm not sure if the later-phase concurrencies
(war, install etc) provide any real value, and some may even have
negative contributions in some case (I/O trashing due to concurrency
comes to mind). I run my builds on ramdisk in linux, so I don't suffer,
but those poor windows users with their crappy IO and virus controls are
not as lucky.
What if we just added a surefire:force-test mojo that would ignore
-DskipTests and -Dmaven.test.skip? Then you could do this:
mvn install surefire:force-test -DskipTests
The "mvn install" part could build at Project Granularity without much
loss; then the surefire:force-test mojo could execute after each module
but in parallel with the rest of the build.
To put it another way, given three projects Z Y X where Z depends on Y
which depends on X, at Project Granularity the builds are just run
linearly:
XCTPI YCTPI ZCTPI
(Compile Test Package Install = CTPI)
In Weave mode we do it like this:
XCTPI
YCTPI
ZCTPI
... but that's dangerous, because Z's Compile may depend on X's Package.
But if we did this:
XCPIT
YCPIT
ZCPIT
The tests are the long part anyway, so this should have considerably
improved concurrency without adding project risk.
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
