I've been thinking for awhile now that we need to find a way to
enable the more common programmatic semantics for mojo ordering...for
instance:
- finally semantics, where a mojo is /always/ executed after another
mojo, regardless of failure status...the only question here is shared
with the programming world: what do we do with failures in the finally
{} mojo? We could list them as successive failures in the build
output, but that doesn't feel complete. Also, we probably need a
syntax to capture which mojo or mojos (phase?) is subject to this
finally "clause".
- execute-on-success mojos, which is basically what fine-grained
control over mojo ordering would give us under the current situation,
since a failure in one mojo typically blocks the execution of the
next one...the only thing that remains is the ability to control very
explicitly which one comes first.
- catch semantics, where a mojo only executes if its predecessor
fails...in this case, the syntax really does have to carry some
attachment to the mojo or group of mojos (phase?) that should be
monitored for failure.
I tried an experiment awhile back to use AspectJ to inject some of
this sort of behavior into the Maven 2.0.x code...it worked as a
proof-of-concept, but needs quite a bit of refinement to make the
syntax easier to swallow...it was handled as a new mojo to inject
this behavior, which is inside-out IMO...the syntax for these
features definitely needs to be baked in.
As for a revert on the clean lifecycle, I'd support an empty
lifecycle phase, but not one with a default scm plugin binding or
anything...this is mainly because the project may not be in source
control at all, or the SCM system may not be supported by maven-scm.
If it's just an empty lifecycle phase, why not just attach the scm
plugin to the post-clean phase? I suppose there is a real benefit to
the verb being clear in this case, though...
-john
On Feb 11, 2008, at 4:44 AM, Stephen Connolly wrote:
Hmmm, spotted that one of my wishes got into my description of the
"current"
main lifecycle, i.e. process-test-classes
I'm thinking that some of those process- phases are also hacks!
Once we have the ability to control the sequence of execution, those
process- phases could be removed... giving us
- validate
- generate-sources
- generate-resources
- compile
- generate-test-sources
- generate-test-resources
- test-compile
- test
- package
- integration-test
- stage
- verify
- install
- deploy
- use
Now only three of these look ugly to me! the test- phases...
OK, so I might have some tool that generates unit or functional
tests based
on annotations in my source code, or byte-code processing, so I do
need a
generate-test-sources phase after compile, and a separate test-
compile phase
after it. Also, test resources might take a while to generate, so
I'm stuck
with having generate-test-resources as a separate phase after
compile...
On a slightly different note, I'd like the clean life-cycle to have
a final
step, "revert". So that we can both clean our produced artifacts,
and revert
our changes!
I'd also change "site-deploy" to "publish" as it is really just
publishing
the site!
On Feb 11, 2008 9:33 AM, Stephen Connolly
<[EMAIL PROTECTED]>
wrote:
From
http://docs.codehaus.org/display/MAVEN/Suppression%2C+Ordering%2C
+and+Replacement+of+Plugins+and+Mojos+Bindings
one critical advantage of Maven over Ant or other build systems is
its
universal, intuitive set of verbs used to build any project, it is
imperative
that we preserve the meaning of these verbs and not water them
down with
subtle variations and modifiers
Allowing people to create new lifecycle phases willy-nilly will
remove the
whole concept of having an intuitive set of verbs that are common
across all
Maven projects.
I agree that the current set of verbs _may_ be missing one or two
phases,
but we need to remember that in some cases the pre- and post-
phases are
just a hack.
Actually, thinking about this a bit more I think that the main
lifecycle
is probably complete and once good mechanisms for replacing
executions and
ordering executions within a phase are available, we should be
able to trim
back the pre- and post- phases to remove the very hacky ones.
Currently, the "Main" lifecycle looks like:
- validate
- generate-sources
- process-sources
- generate-resources
- process-resources
- compile
- process-classes
- generate-test-sources
- process-test-sources
- generate-test-resources
- process-test-resources
- test-compile
- process-test-classes
- test
- package
- pre-integration-test
- integration-test
- post-integration-test
- verify
- install
- deploy
Now, I understand why we have a pre-integration-test and a
post-integration-test phase. The idea being that we'd attach a mojo
execution to the pre-test that starts up our integration test
environment
and another to the post-integration-test phase that stops the
container for
us...
I was going to write that I'd want a pre-test and a post-test
phase as
well because sometimes I want a mock container that is started up
for unit
and functional tests... but then what happens when I type "mvn
test" or "mvn
integration-test"? My container is started and never stopped!
What I really want is a way to wrap a phase with a mojo, that gets
rid of
the need for all the pre- and post- phases that people look for.
I also think we need a separate phases for roll-out type
activities, I
would propose placing one phase between integration-test and verify
- ...
- package
- integration-test (as these are tests of the package)
- stage (my idea here is that we deploy the artifact to a dev- or
qa- container)
- verify (here is where I would bind acceptance tests)
- install
- ...
and the other phase after deploy
- ...
- deploy
- use (my idea here is that we deploy the artifact to the live
environment!)
On Feb 11, 2008 8:44 AM, Wouter Hermeling <[EMAIL PROTECTED]>
wrote:
Reading through the Deterministic Lifecycle Planning page...
Do these changes make it possible to create new lifecycle phases???
Imho this would really help maven to become an extendable build/
project
management tool for multiple platforms and purposes.
--
View this message in context:
http://www.nabble.com/Please-comment%3A-2.1-Lifecycle-Features-on-
MAVEN-Confluence-space-tp15170452s177p15407416.html
Sent from the Maven Developers mailing list archive at Nabble.com.
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
