I've been meaning to reply to your earlier emails (it's been a busy week);
to this I'll just say that moving the "test" phase after the "install"
phase is a fascinating idea, which I personally like, but it seems like a
big violation of the contract for the lifecycle, and I suspect it won't be
popular. :-(
I've long felt that there should be a phase for testing after "install"
for similar reasons. This might be SLIGHTLY more popular since users
would need to explicitly cause their tests to run during this phase.
What about users doing multi-machine builds? Earlier this week I wrote
that users desiring to do multi-machine parallelism should deploy their
builds to a remote repository shared between the machines. Should their
tests run post-deploy?
-Dan
Kristian Rosenvold wrote:
I've been thinking further about parallelity within maven. The proposed
solution to MNG-3004
achieves parallelity by analyzing inter-module dependencies and scheduling
parallel dependencies in parallel.
A simple further evolution of this would be to collect and download all
external dependencies
for all modules immediately.
But this idea has been rummaging in my head while jogging for a week or so:
Would it be possible to achieve super-parallelity by describing
relationships between phases of the build, and even reordering some of the
phases ? I'll try to explain:
Assume that you can add transactional ACID (or maybe just AID) abilities
towards the local
repo for a full build. Simply put: All writes to a local repo is done in a
per-process-specific instance of the repo, that can be rolled back if the
build fails (or pushed to the local repo if
the build is ok)
If you do that you can re-order the life-cycle for most builds to be
something like this:
validate
compile
package
install
test
integration-test
deploy
Notice that I just moved all the "test" phases after the "install" phase.
Theoretically you could start any subsequent modules immediately after
"install" is done. Running of tests is really the big killer in most
multi-module projects I see.
Since your commit "push" towards the local repo only happens at the very end
of the build, you
will not publish artifacts when tests are failing (at leas not project
output artifacts)
You could actually make this a generic model that describes deifferent kinds
of
dependencies between lifecycle phases of different modules. The dependency I
immediately
see is "requiredForStarting" - which could be interpreted as meaning that
any upstream
dependencies must have reached at least that phase before the phase can be
started
for this project. I'm not sure if there's any value in a generic model, but
my perspective
may be limited to what I see on a daily basis.
Would this be feasible ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
