GMaven
  1. GMaven
  2. GMAVEN-79

Cannot use @Test(expected=...) without .class suffix

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.2
    • Fix Version/s: None
    • Component/s: stub generation
    • Labels:
      None
    • Testcase included:
      yes
    • Number of attachments :
      0

      Description

      I have a test, which looks like this:

          @Test(expected = IllegalArgumentException)
          void shouldFailOnDifferentCurrencies() {
             // impl
          }
      

      This results in the following error message when using the GMaven-1.2 stub compiler:

      symbol  : variable IllegalArgumentException
      location: class com.nidera.softmar.abw.gl.preprocessor.MultiCurrencyPreprocessorTest
      

      In my IDE (IntelliJ 9.0.3) this works however, which leads me to believe this is quite valid. Adding a .class suffix to the expected class fixes this, but I guess that this is an issue in the stub generation.

        Issue Links

          Activity

          Hide
          Peter Niederwieser added a comment -

          It's likely that this is a bug in groovyc's stub generator and not GMaven's fault. To verify, check "IDEA -> Preferences -> Compiler -> Groovy Compiler -> Use groovyc's native stub generator" and see if you get the same error in IDEA. By default, IDEA uses its own stub generator, which is more mature than Groovy's.

          Meanwhile, are you sure you need stub generation for your tests (i.e. do you have Java->Groovy dependencies in your tests)?

          Show
          Peter Niederwieser added a comment - It's likely that this is a bug in groovyc's stub generator and not GMaven's fault. To verify, check "IDEA -> Preferences -> Compiler -> Groovy Compiler -> Use groovyc's native stub generator" and see if you get the same error in IDEA. By default, IDEA uses its own stub generator, which is more mature than Groovy's. Meanwhile, are you sure you need stub generation for your tests (i.e. do you have Java->Groovy dependencies in your tests)?
          Hide
          Erik Pragt added a comment -

          Hi Peter, thanks for the reply.

          I changed the Stub generation in IntelliJ to use the native stub generator, and it compiles without problems, so my guess is that it's still a GMaven thing.

          I probably don't need stub generation for my tests, but how can I control that? I just did a mvn clean install, which generates all the stub's for me, even for my tests. Can I turn it off explicitly? However, I don't think that will change anything. If I have a class which looks likes this:

          class Person {
             @Mapping(mapping=SomeTypeMapper)
             private Field typeToMap
          }
          

          My guess (haven't tested it yet) is that this will also fail in GMaven.

          Show
          Erik Pragt added a comment - Hi Peter, thanks for the reply. I changed the Stub generation in IntelliJ to use the native stub generator, and it compiles without problems, so my guess is that it's still a GMaven thing. I probably don't need stub generation for my tests, but how can I control that? I just did a mvn clean install, which generates all the stub's for me, even for my tests. Can I turn it off explicitly? However, I don't think that will change anything. If I have a class which looks likes this: class Person { @Mapping(mapping=SomeTypeMapper) private Field typeToMap } My guess (haven't tested it yet) is that this will also fail in GMaven.
          Hide
          Peter Niederwieser added a comment -

          >I changed the Stub generation in IntelliJ to use the native stub generator, and it compiles without problems, so my guess is that it's still a GMaven thing.
          Strangely, most stub-generation related bugs I've come across are GMaven-only, although it uses Groovy's stub generator. There must be something wrong with the integration.

          >I probably don't need stub generation for my tests, but how can I control that?
          If you don't need joint compilation, by all means leave out the generateStubs/generateTestStubs goals. You can have a look at this POM: http://code.google.com/p/spock/source/browse/branches/groovy-1.7/pom.xml (search for 'gmaven-plugin')

          >My guess (haven't tested it yet) is that this will also fail in GMaven.
          Probably. Have you verified that you need stub generation for your production code? And have you configured GMaven to use the latest Groovy version (1.6.9 or 1.7.4)?

          Show
          Peter Niederwieser added a comment - >I changed the Stub generation in IntelliJ to use the native stub generator, and it compiles without problems, so my guess is that it's still a GMaven thing. Strangely, most stub-generation related bugs I've come across are GMaven-only, although it uses Groovy's stub generator. There must be something wrong with the integration. >I probably don't need stub generation for my tests, but how can I control that? If you don't need joint compilation, by all means leave out the generateStubs/generateTestStubs goals. You can have a look at this POM: http://code.google.com/p/spock/source/browse/branches/groovy-1.7/pom.xml (search for 'gmaven-plugin') >My guess (haven't tested it yet) is that this will also fail in GMaven. Probably. Have you verified that you need stub generation for your production code? And have you configured GMaven to use the latest Groovy version (1.6.9 or 1.7.4)?
          Hide
          Erik Pragt added a comment -

          The most bugs I experience with GMaven are related to stub generation (like all imports missing, and currently the issue for BigDecimal).

          I don't know if I need joint compilation, but I just don't need it for my tests.

          No, I haven't verified that I need it. At the moment, I probably don't, for as far as I know, we only use Groovy code. I'm currently using 1.7.4 in combination with GMaven.

          But either I turn it on or off, it's still an issue people could by affected by.

          Show
          Erik Pragt added a comment - The most bugs I experience with GMaven are related to stub generation (like all imports missing, and currently the issue for BigDecimal). I don't know if I need joint compilation, but I just don't need it for my tests. No, I haven't verified that I need it. At the moment, I probably don't, for as far as I know, we only use Groovy code. I'm currently using 1.7.4 in combination with GMaven. But either I turn it on or off, it's still an issue people could by affected by.
          Hide
          Peter Niederwieser added a comment -

          Of course these things should be fixed. I'm just saying that it's always better to turn off joint compilation if you don't need it. This will speed up compilation significantly and save you from a lot of troubles (stub generation bugs, incompatibility with AST transforms, problems with tools and IDEs).
          You only need joint compilation if you have Java classes that reference Groovy classes in the same Maven module. As long as you keep dependencies within a module unidirectional (Groovy->Java), you don't need joint compilation.

          Show
          Peter Niederwieser added a comment - Of course these things should be fixed. I'm just saying that it's always better to turn off joint compilation if you don't need it. This will speed up compilation significantly and save you from a lot of troubles (stub generation bugs, incompatibility with AST transforms, problems with tools and IDEs). You only need joint compilation if you have Java classes that reference Groovy classes in the same Maven module. As long as you keep dependencies within a module unidirectional (Groovy->Java), you don't need joint compilation.
          Hide
          Jason Dillon added a comment -

          This is a problem with the Groovy stub-generator. I've just setup a simple test project using groovyc and the stub that gets generated for @Test(expected=IllegalArgumentException) does not get .class appended. The groovyc task seems to be fine to let this slide, perhaps because it knows that its not actually going to compile that stub? Anyways, adding a javac afterwards to ensure that the stubs are compilable shows that they clearly are not.

          This is what I am using more or less to drive/test it:

          <project default="all">
          
              <property name="groovy.jar" value="groovy-all-1.7.4.jar"/>
          
              <target name="all">
                  <taskdef name="groovyc" classname="org.codehaus.groovy.ant.Groovyc">
                      <classpath>
                          <pathelement location="${groovy.jar}"/>
                      </classpath>
                  </taskdef>
          
                  <delete dir="target"/>
                  <mkdir dir="target/classes"/>
                  <mkdir dir="target/stubs"/>
          
                  <groovyc srcdir="src" destdir="target/classes" stubdir="target/stubs" keepstubs="true">
                      <classpath>
                          <pathelement path="target/classes"/>
                          <pathelement location="${groovy.jar}"/>
                          <fileset dir="lib">
                              <include name="*.jar"/>
                          </fileset>
                      </classpath>
                      <javac source="1.5" target="1.5" debug="on"/>
                  </groovyc>
          
                  <mkdir dir="target/stub-classes"/>
                  <javac srcdir="target/stubs" destdir="target/stub-classes" source="1.5" target="1.5">
                      <classpath>
                          <pathelement path="target/classes"/>
                          <pathelement location="${groovy.jar}"/>
                          <fileset dir="lib">
                              <include name="*.jar"/>
                          </fileset>
                      </classpath>
                  </javac>
              </target>
          
          </project>
          
          Show
          Jason Dillon added a comment - This is a problem with the Groovy stub-generator. I've just setup a simple test project using groovyc and the stub that gets generated for @Test(expected=IllegalArgumentException) does not get .class appended. The groovyc task seems to be fine to let this slide, perhaps because it knows that its not actually going to compile that stub? Anyways, adding a javac afterwards to ensure that the stubs are compilable shows that they clearly are not. This is what I am using more or less to drive/test it: <project default= "all" > <property name= "groovy.jar" value= "groovy-all-1.7.4.jar" /> <target name= "all" > <taskdef name= "groovyc" classname= "org.codehaus.groovy.ant.Groovyc" > <classpath> <pathelement location= "${groovy.jar}" /> </classpath> </taskdef> <delete dir= "target" /> <mkdir dir= "target/classes" /> <mkdir dir= "target/stubs" /> <groovyc srcdir= "src" destdir= "target/classes" stubdir= "target/stubs" keepstubs= "true" > <classpath> <pathelement path= "target/classes" /> <pathelement location= "${groovy.jar}" /> <fileset dir= "lib" > <include name= "*.jar" /> </fileset> </classpath> <javac source= "1.5" target= "1.5" debug= "on" /> </groovyc> <mkdir dir= "target/stub-classes" /> <javac srcdir= "target/stubs" destdir= "target/stub-classes" source= "1.5" target= "1.5" > <classpath> <pathelement path= "target/classes" /> <pathelement location= "${groovy.jar}" /> <fileset dir= "lib" > <include name= "*.jar" /> </fileset> </classpath> </javac> </target> </project>
          Hide
          Jason Dillon added a comment -

          I've put this into a project here:

          Show
          Jason Dillon added a comment - I've put this into a project here: http://github.com/jdillon/groovy-stub-test
          Hide
          Erik Pragt added a comment -

          Hi Jason,

          What's next? Should I report this bug in the Groovy project?

          Erik

          Show
          Erik Pragt added a comment - Hi Jason, What's next? Should I report this bug in the Groovy project? Erik
          Hide
          Erik Pragt added a comment -

          Hi Jason,

          What's next? Should I report this bug in the Groovy project?

          Erik

          Show
          Erik Pragt added a comment - Hi Jason, What's next? Should I report this bug in the Groovy project? Erik
          Hide
          Peter Niederwieser added a comment -

          Yes, please do report a bug. I'm looking into it right now.

          Show
          Peter Niederwieser added a comment - Yes, please do report a bug. I'm looking into it right now.
          Hide
          Erik Pragt added a comment -

          Done. See GROOVY-4354

          Show
          Erik Pragt added a comment - Done. See GROOVY-4354
          Hide
          Jason Dillon added a comment -

          I also just mailed the list with details.

          Show
          Jason Dillon added a comment - I also just mailed the list with details.
          Hide
          Jason Dillon added a comment -

          Stub generation (and compilation) is no longer supported by GMaven. The groovy-eclipse-compiler should be used instead:

          http://docs.codehaus.org/display/GROOVY/Groovy-Eclipse+compiler+plugin+for+Maven

          Sorry for the inconvenience, but there are irreconcilable problems with GMavens legacy stub-compiler, or its integration with the modern Groovy compiler wrt to lifecycle integration with Maven.

          The groovy-eclipse-compiler components solve these problems very well and it should be used for all groovy compilation needs inside of Maven.

          Show
          Jason Dillon added a comment - Stub generation (and compilation) is no longer supported by GMaven. The groovy-eclipse-compiler should be used instead: http://docs.codehaus.org/display/GROOVY/Groovy-Eclipse+compiler+plugin+for+Maven Sorry for the inconvenience, but there are irreconcilable problems with GMavens legacy stub-compiler, or its integration with the modern Groovy compiler wrt to lifecycle integration with Maven. The groovy-eclipse-compiler components solve these problems very well and it should be used for all groovy compilation needs inside of Maven.

            People

            • Assignee:
              Unassigned
              Reporter:
              Erik Pragt
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: