Details

    • Flags:
      Patch

      Description

      Namely:

      • generate-integration-test-sources
      • process-integration-test-sources
      • generate-integration-test-resources
      • process-integration-test-resources
      • integration-test-compile

      and possibly a:

      • integration-test-package
      1. MNG-2010-maven-lifecycle.patch
        21 kB
        Nelz Carpentier
      2. MNG-2010-site.patch
        4 kB
        Nelz Carpentier

        Issue Links

          Activity

          Vincent Massol created issue -
          Vincent Massol made changes -
          Field Original Value New Value
          Workflow Maven [ 46631 ] Maven New [ 47696 ]
          John Casey made changes -
          Fix Version/s 2.0.5 [ 12294 ]
          kenneyw made changes -
          Fix Version/s 2.0.6 [ 13010 ]
          Fix Version/s 2.0.5 [ 12294 ]
          Jason van Zyl made changes -
          Fix Version/s 2.0.6 [ 13010 ]
          Fix Version/s 2.0.x [ 13141 ]
          Hide
          Nelz Carpentier added a comment -

          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...

          Show
          Nelz Carpentier added a comment - 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...
          Hide
          Nelz Carpentier added a comment -

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

          Show
          Nelz Carpentier added a comment - The changes to the documentation to go along with the new lifecycle phases.
          Nelz Carpentier made changes -
          Attachment MNG-2010-site.patch [ 27604 ]
          Hide
          Nelz Carpentier added a comment -

          The actual changes to the lifecycle, including additional tests.

          Show
          Nelz Carpentier added a comment - The actual changes to the lifecycle, including additional tests.
          Nelz Carpentier made changes -
          Attachment MNG-2010-maven-lifecycle.patch [ 27605 ]
          Jason van Zyl made changes -
          Patch Submitted [Yes]
          Hide
          Jason van Zyl added a comment -

          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.

          Show
          Jason van Zyl added a comment - 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.
          Hide
          John Casey added a comment -

          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.

          Show
          John Casey added a comment - 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.
          John Casey made changes -
          Patch Submitted [Yes]
          Description Namely:
          * generate-integration-test-sources
          * process-integration-test-sources
          * generate-integration-test-resources
          * process-integration-test-resources
          * integration-test-compile

          and possibly a:
          * integration-test-package
          Namely:
          * generate-integration-test-sources
          * process-integration-test-sources
          * generate-integration-test-resources
          * process-integration-test-resources
          * integration-test-compile

          and possibly a:
          * integration-test-package
          Hide
          Nelz Carpentier added a comment -

          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.

          Show
          Nelz Carpentier added a comment - 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.
          Hide
          Kenney Westerhof added a comment -

          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.

          Show
          Kenney Westerhof added a comment - 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.
          Hide
          Nelz Carpentier added a comment - - edited

          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. Is it in SVN, under https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/? I'll start looking at that soon...

          Show
          Nelz Carpentier added a comment - - edited 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. Is it in SVN, under https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/? I'll start looking at that soon...
          Brett Porter made changes -
          Patch Submitted [Yes]
          Hide
          Brian E. Fox added a comment -

          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

          Show
          Brian E. Fox added a comment - 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
          Brian Fox made changes -
          Fix Version/s 2.1 [ 13142 ]
          Fix Version/s 2.0.x [ 13141 ]
          Benjamin Bentmann made changes -
          Link This issue is related to MNG-2009 [ MNG-2009 ]
          Jason van Zyl made changes -
          Fix Version/s 3.0 [ 13142 ]
          Fix Version/s 3.x [ 13145 ]
          Show
          Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
          Hide
          Jason van Zyl added a comment -

          Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

          Show
          Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.
          Jason van Zyl made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Incomplete [ 4 ]
          Paul Benedict made changes -
          Fix Version/s Issues to be reviewed for 3.x [ 13145 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 08:49:45 UTC 2015 [ 1428223785911 ]
          Mark Thomas made changes -
          Workflow jira [ 12712697 ] Default workflow, editable Closed status [ 12752544 ]
          Mark Thomas made changes -
          Patch Submitted Yes [ 10763 ]
          Flags Patch [ 10430 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 21:45:26 UTC 2015 [ 1428270326204 ]
          Mark Thomas made changes -
          Workflow jira [ 12952263 ] Default workflow, editable Closed status [ 12989601 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          2919d 17h 26m 1 Jason van Zyl 22/Jan/14 20:31

            People

            • Assignee:
              Unassigned
              Reporter:
              Vincent Massol
            • Votes:
              12 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development