Hi everyone,
I wanted to start a discussion about the current drawbacks involved with:
* suppression of inherited/injected/packaging-mapped mojo bindings
* ordering of new mojo bindings within a phase that already contains other
bindings
* replacement of one mojo binding with another
As we've all seen over the past year or more, the lifecycle phase list has
been growing. In most cases, this is because we're finding needs for more
fine-grained control over placement of mojos in the lifecycle relative to
other mojos. Sometimes, we need to pre-process the list of files slated for
inclusion in the project artifact - so we introduce the pre-package
lifecycle phase, to get ahead of the jar plugin. Sometimes, we need to setup
a unit- or integration-testing environment, or tear one down - so, we
introduce pre- and post-*test (eg. pre-integration-test) phases.
I see two serious problems with this approach. First, we're dealing with a
potentially limitless number of mojo bindings in a given lifecycle,
particularly when relatively large inheritance structures are involved, or
when Maven is used for building other languages (like the c-builds plugins
for orchestrating Make builds shows). The ability to add a new mojo binding
to a given phase without running into ordering problems when that phase
already contains bindings depends on the bindings being completely
independent of one another...which we've seen is not always the case. The
other problem is that phases like post-integration-test only execute when
you invoke a lifecycle phase >= post-integration-test...in other words,
executing `mvn integration-test` will NOT result in the integration-testing
environment being cleaned up. IMO, this makes the post-integration-test
phase a little misleading, since it seems to imply a tear-down step that
runs with finally{} semantics.
Beyond the ordering vs. phase addition conversation, we still have problems
with suppressing mojos that are configured to cover the 80% case in a large
development environment...and the possibility of replacement with some other
mojo tailored for the 20% case. If the mojo binding in question happens to
be the first in a list of bindings for that phase, it's not currently
possible to replace it without pushing the new mojo binding up to an earlier
phase. If the binding is the second of three for that phase, it's simply
impossible to replace it.
This will not fix everything wrong with lifecycles and plugins; it's only
aimed to resolve the three issues above. However, I've spent some time
talking to Brett and Jesse, and I think I've got a good starting point for
this discussion. See:
http://docs.codehaus.org/display/MAVEN/Suppression%2C+Ordering%2C+and+Replacement+of+Plugins+and+Mojos+Bindings
to read on. I'll also post the content in a reply to this message.
Any comments/discussion that lands here will be paraphrased on the wiki page
for posterity. :-)
Thanks!
-john
