Getting exceptions when using ProjectBuilder to test gradle plugins after moving from Gradle 1.1 to 1.2

(Eric Deandrea) #1

After moving from Gradle 1.1 to 1.2 we are seeing exceptions when testing our plugins.

This is the line of code that is generating the exception

def proj = ProjectBuilder.builder().withName("SomeProjectName").withProjectDir(new File("target/resources/test", "SomeProjectName")).build()

This is the exception

Running test: test testBasePluginExposesProperties( > testBasePluginExposesProperties FAILED
    org.gradle.api.GradleException: Could not generate a proxy class for class org.gradle.api.internal.project.DefaultPr
        at org.gradle.api.internal.AbstractClassGenerator.generate(
        at org.gradle.api.internal.ClassGeneratorBackedInstantiator.newInstance(
        at org.gradle.api.internal.project.ProjectFactory.createProject(
        at org.gradle.api.internal.project.ProjectFactory.createProject(
        at org.gradle.testfixtures.internal.ProjectBuilderImpl.createProject(
          Caused by:
        java.lang.IncompatibleClassChangeError: Found interface org.objectweb.asm.MethodVisitor, but class was expected
            at org.gradle.api.internal.AsmBackedClassGenerator$ClassBuilderImpl.addGetter(
            at org.gradle.api.internal.AsmBackedClassGenerator$ClassBuilderImpl.addGetter(
            at org.gradle.api.internal.AsmBackedClassGenerator$ClassBuilderImpl.mixInGroovyObject(AsmBackedClassGenerato
            at org.gradle.api.internal.AbstractClassGenerator.generate(
            ... 7 more

(Dan Stine) #2

We ran into a similar problem. We use Cobertura to measure code coverage, don’t know if you happen to do the same? Here is the relevant forum discussion.

(Eric Deandrea) #3

I did see that post - we are not using cobertura, although we are using jacoco. Its only when using the method that we run into this problem - when I take my custom distro and run a build of another project, all of the instrumentation & everything works fine.

(Luke Daley) #4

It’s the same problem as with Cobertura. JaCoCo uses ASM in the same way.

From memory, you need to block JaCoCo pulling in its asm dependency during test time. In the Cobertura plugin, I rewrote it to ensure that cobertura and its dependencies are added to the runtime classpath after the actual runtime dependencies. This will fix it too.

(Eric Deandrea) #5

So how do I go ahead and fix this issue? I am placing jacoco into its own configuration and then adding the dependencies to that configuration. How do I make sure it is added to the classpath after all of the other runtime dependencies?

(Luke Daley) #6

It’s hard to say without knowing how your project is configured, but something like…

test {
  classpath = configurations.runtime + configurations.jacoco

(Eric Deandrea) #7

I figured out my issue. Like Dan, I had originally included the jacoco libraries in my testRuntime configuration (I just scan for all .jar files in a lib/testRuntime directory for the testRuntime configuration). I was keeping the jacoco jars in that testRuntime directory, even though I had then created a separate configuration for them. I took them out of the testRuntime directory and now everything seems to work fine. Thanks!