Add new lifecycle phases for IT

I am attaching the patch(es) that I've made to address this.

Here's my description:
1) I added the five phases above.
2) I have also added a "pre-test" and "post-test" around the standard "test" target. This is for two reasons: a) it's appeals to my sense of symmetry , and b) I have found a need for those phases in the past.
3) I added comments to a method that assumes the phase names across different lifecycles are unique.
4) I added some tests of the model objects that get created.
5) I added a couple of tests that enforce unique phase names.
6) I added the documentation of these build phases to the "The Build Lifecycle" mini-guide.

I was able to get the "site" documentation to build successfully. Though I was able to get the "maven-lifecycle" to build successfully, I was not able to get all the "components" to build successfully. So, I downloaded a fresh copy, and the failure happened in the same place. ("BuildPlan" is missing in the "maven-core" component?) I figured that if "maven-lifecycle" build correctly, and the "components" failed in the same place as a fresh pull-down, I have "done no harm", and am fairly confident that my changes will work as expected.

I did the changes against the main-line, though this JIRA seems to indicate I should have done it against 2.0.X...? I think my changes should still fit in well...

After this, I will continue looking into the compile and surefire plugins...

The changes to the documentation to go along with the new lifecycle phases.

The actual changes to the lifecycle, including additional tests.

These look good at first blush but we need to decide whether we are going to work toward the pattern of having integration tests in separate modules before adding these. The lifecycle is getting pretty good and I would rather use the existing test phases and encourage separate modules to do integration testing. I think one module will get out of hand with the possibility of 35 phases.

I'm really not happy with the approach of forever adding new phases to the lifecycle. This particular issue is an extreme example, but we really need to remember that each addition to the lifecycle is an addition to the build vocabulary of Maven. Are we ever really going to stop the build at the 'generate-integration-test-resources' phase??? What about 'integration-test-package'...how do you invoke that? The answer is that you've changed the build vocabulary such that if you want to really capture the integration tests as they were meant to be captured, you have to do:

mvn integration-test-package

Also, we have no provision in the lifecycle for post-processing for cleanup, which can be critical for integration tests. To me, this is just putting more tape on an already large ball of the same.

To Jason:
If we take the "simple" example of a self-contained web application with just a single WAR artifact, I think that requiring a multi-module build is kind of overkill. (In an enterprise scenario, I can see separating out the tests, especially if there is a client generated from the single WAR artifact, as is the case with Web Services...)

Hypothetically, let's look at a multi-module with the first module building the WAR file, and a second module to test the WAR file. What stops a developer from going down to the first module and just building/deploying that artifact? Now, the artifact is uploaded to whatever internal repository without being tested.

One of the things I really cherish about the Maven lifecycle is how it enforces that tests must pass before the artifact makes out of the local box...

To John:
I do think these phases are important, for all the same reasons they are important before the (unit) tests. And, much like what I said above, I think it is very important to test before it gets out of the current developer's workspace. You are right, we probably won't have many people typing "mvn process-integration-test-resources" (other than the build developers who want to test up to that point...), but we sure will have people typing "mvn install". And in my opinion, having the integration tests do their thing before that 'install' point is muy importante...

Also, there is already provision for doing post-processing for cleanup, it's the "post-integration-test"... And if you are talking about using the (unit) test functionality for doing the post-processing stuff in a multi-module build, that is why I added the "post-test" phase in my submitted patch...

To No One In Particular:
I believe the two parallel cycles of 'test' and 'integration-test' are important for robust artifacts. The (unit) tests serve to test as a white-box, co-locate type of environment, and the integration tests serve to test the artifact like a black-box, separate client.

I have to agree with jason and john - keep the lifecycle small.

About a year ago I started the maven-it-plugin, with the idea of using any standard lifecycle as a 'forked' sub-lifecycle.
the 'integration-test' phase would run maven (embedded) on src/it/*/pom.xml, where each project could run any lifecycle
they wish - by specifying a packaging. Normally you'd just have some tests in src/test/ which get executed.

This way you can run multiple integration tests, without separate modules (unless you see src/it/* as modules).
I think this, or something similar, is the way to go. We cannot simply grow the main lifecycle any time another usecase comes up.
it's already too big - there should be just one integration-test phase; i don't even see the need for the pre- and post- phases there.
It should be a hook to run a new lifecycle, like a subroutine. That should be flexible enough for anybody.

I think we've decided in the past not to add new phases, i'm tempted to close this but at a minimum it should go to 2.1