Maven 1.x Test Plugin
  1. Maven 1.x Test Plugin
  2. MPTEST-66

1.8 version introduces bug in other plugins

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.8
    • Fix Version/s: 1.8.1
    • Labels:
      None
    • Number of attachments :
      1

      Description

      When maven-war-plugin is run with maven.test.skip=true, the sources are not compiled.
      Latest version of test-plugin has removed prereqs on java:compile & java:jar-resources.
      Assuming other plugins themself run the java:compile goal may have impact on lots of plugin and can break many application builds. I think the "test:test" goal may have a prereqs="java:compile,java:jar-resources", and the "test:compile" goal only prereqs="test:prepare-filesystem,test:test-resources"

        Issue Links

          Activity

          Hide
          Shinobu Kawai added a comment -

          Actually, it's going to compile twice anyways (unless we revert the whole MPTEST-46 fix) because test:compile is being attainGoal-ed, and that will call java:compile.

          java:compile and java:jar-resources will do nothing on the second time, so the only impact would be if pre/postGoal's were set in maven.xml.

          Show
          Shinobu Kawai added a comment - Actually, it's going to compile twice anyways (unless we revert the whole MPTEST-46 fix) because test:compile is being attainGoal-ed, and that will call java:compile. java:compile and java:jar-resources will do nothing on the second time, so the only impact would be if pre/postGoal's were set in maven.xml.
          Hide
          nicolas de loof added a comment -

          Lot's of code generation plugin are attached to java:compile as preGoals...

          I can suggest two options :

          1. keep previous behaviour and assume test:* allways depends on java:compile, even if this is not clean.

          2. make ONLY the "test" goal (not the "test:test") depend on java:compile, so that a

          • "maven test" compiles project and run the tests, as any user may expect it
          • any plugin depending on test:test will NOT force a twice compilation.
            This 2d solution requires update to other plugins.

          Any 3d solution would be welcome as both seems not very cool...

          Show
          nicolas de loof added a comment - Lot's of code generation plugin are attached to java:compile as preGoals... I can suggest two options : 1. keep previous behaviour and assume test:* allways depends on java:compile, even if this is not clean. 2. make ONLY the "test" goal (not the "test:test") depend on java:compile, so that a "maven test" compiles project and run the tests, as any user may expect it any plugin depending on test:test will NOT force a twice compilation. This 2d solution requires update to other plugins. Any 3d solution would be welcome as both seems not very cool...
          Hide
          Shinobu Kawai added a comment -

          Not clear how the whole prereqs stuff work, but I was wondering if adding an attribute to call attainGoal with the same werkz session would work.

          Something like <attainGoal name="java:compile" useParentSession="true" />.

          Show
          Shinobu Kawai added a comment - Not clear how the whole prereqs stuff work, but I was wondering if adding an attribute to call attainGoal with the same werkz session would work. Something like <attainGoal name="java:compile" useParentSession="true" />.
          Hide
          Lukas Theussl added a comment -

          We need to decide what to do about this issue for m11. Personally, I don't want to revert MPTEST-46 as the current way is the way it should be. Also, we have already adapted our other plugins to it (MPEJB-23, MPWAR-62, jar), so internally, we are clean. The only problem is with backward compatibility when using third-party plugins that rely on java:compile being called with test:test. For this case, there is a simple workaround, eg for the javaapp plugin, add the following in your maven.xml:

          <preGoal name="javaapp:jar">
            <j:if test="${unitTestSourcesPresent != 'true' or context.getVariable('maven.test.skip') == 'true'}">
              <attainGoal name="java:compile"/>
              <attainGoal name="java:jar-resources"/>
            </j:if>
          </preGoal>
          

          Sources being compiled twice is not a real problem (and btw it was that way before already), as the second time only the goal will be called but the sources not actually compiled.

          So my suggestion is to leave it as is and write a paragraph on the main plugin page to document the problem. Unless someone comes up with a new solution, as none of the alternatives above seem acceptable to me.

          Show
          Lukas Theussl added a comment - We need to decide what to do about this issue for m11. Personally, I don't want to revert MPTEST-46 as the current way is the way it should be. Also, we have already adapted our other plugins to it ( MPEJB-23 , MPWAR-62 , jar), so internally, we are clean. The only problem is with backward compatibility when using third-party plugins that rely on java:compile being called with test:test. For this case, there is a simple workaround, eg for the javaapp plugin, add the following in your maven.xml: <preGoal name= "javaapp:jar" > <j:if test= "${unitTestSourcesPresent != 'true' or context.getVariable('maven.test.skip') == 'true'}" > <attainGoal name= "java:compile" /> <attainGoal name= "java:jar-resources" /> </j:if> </preGoal> Sources being compiled twice is not a real problem (and btw it was that way before already), as the second time only the goal will be called but the sources not actually compiled. So my suggestion is to leave it as is and write a paragraph on the main plugin page to document the problem. Unless someone comes up with a new solution, as none of the alternatives above seem acceptable to me.
          Hide
          Lukas Theussl added a comment -

          Documented the issue.

          Show
          Lukas Theussl added a comment - Documented the issue.

            People

            • Assignee:
              Lukas Theussl
              Reporter:
              nicolas de loof
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: