|
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: 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 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. This way you can run multiple integration tests, without separate modules (unless you see src/it/* as modules). To Kenny:
You convinced me. I really like the sound of the "maven-it-plugin"... It is much less 'literal' than the approach I was originally going with... Plus, it addresses my concerns about putting the tests for a war into a "second pass"... My only concern is this: MNG-1922 seemed to call into question the "maven-it-plugin" and it's functionality for testing anything outside of a Maven plugin... Is this still a problem/question? In the end, the "maven-it-plugin" sounds like it will scratch some itches I've been having. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Open
Major
Add new lifecycle phases for IT
, 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... 
Here's my description:
, and b) I have found a need for those phases in the past.
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
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...