I'm conceptually using the transactional "local" repository as a get-out-of-jail card for possible violations of contract, the full build must be ok for the real repository update to come through, creating any publicly visible artifacts.
Obviously, you're right, the tests should be pushed to after "deploy". I feel this would be comparable to the out-of-order execution and pipelining that modern CPUs do; they guarantee that the underlying contract is unchanged and only do these secret optimizations because they can get away with it without telling you. The question is really it could be pulled off in the same manner as CPU's do it; without fundamentally breaking any contracts...? Kristian al local repository as On Fri, 2009-11-20 at 06:29 -0800, Dan Fabulich wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
