0

I'm working through the exercises in Beginning Java EE 7 except I'm trying to adapt them to use Gradle instead of Maven. For the chapter 2 interceptor exercise, I wrote this build.gradle:

apply plugin: 'java'
repositories {
  mavenCentral()
}
dependencies {
    compile 'org.slf4j:slf4j-api:1.7.5', 'org.jboss.weld.se:weld-se-core:2.2.10.Final'
    testCompile "junit:junit:4.11"
}
jar {
    from {
        configurations.compile.collect {
            it.isDirectory() ? it : zipTree(it)
        }
    }
    manifest {
        attributes 'Main-Class': 'org.agoncal.book.javaee7.chapter02.Main'
    }
}

I'm just using the src dir directly from the author's GitHub. ./gradlew -x test build succeeds and then java -jar build/libs/gradleTest.jar gives the expected output (although it also spits out a lot of unexpected warnings). ./gradlew test however fails with this error:

org.jboss.weld.exceptions.DeploymentException: WELD-001417: Enabled interceptor class <class>org.agoncal.book.javaee7.chapter02.LoggingInterceptor</class> in file:/home/allen/gradleTest/build/resources/main/META-INF/beans.xml@7 does not match an interceptor bean: the class is not found, or not annotated with @Interceptor and still not registered through a portable extension, or not annotated with @Dependent inside an implicit bean archive

The beans.xml and all the class files are straight from the author's repo on GitHub and appear to be exactly as the above error says they're not. The beans.xml declares the interceptor, and the interceptor class is annotated with @Interceptor.

My guess is that the problem lies with my gradle build. Does anyone see what the problem is?

Allen
  • 478
  • 9
  • 21

2 Answers2

1

Allen, I'm assuming you are doing the same example: agoncal-book-javaee7/chapter02/chapter02-putting-together.

When I tried "mvn test" it works and found the difference between the build/target directory between maven and gradle. Maven combines both classes and resources in one directory (as you would before packaging it in jar) but gradle separates the two, one folder for classes and another for resources. The WeldContainer use for testing was unable to pickup the class when reading the beans.xml.

Here's my build.gradle:

apply plugin: 'java'
repositories {
    mavenCentral()
}
dependencies {
    compile 'org.slf4j:slf4j-api:1.7.5', 'org.jboss.weld.se:weld-se-core:2.2.10.Final'

        compile 'org.eclipse.persistence:org.eclipse.persistence.jpa:2.5.2'

        compile 'javax:javaee-api:7.0'
        compile 'org.apache.derby:derby:10.10.1.1'
        testCompile "junit:junit:4.11"
}

test.doFirst {
    copy { 
        from 'build/resources/test/META-INF/beans.xml'
        into 'build/classes/main/META-INF'
    }
    copy { 
        from 'build/resources/test/META-INF/beans.xml'
        into 'build/classes/test/META-INF'
    }
}

Result when running it:

> chapter02-putting-together git:(master) X gradle clean test
:clean
:compileJava
:processResources
:classes
:compileTestJava
:processTestResources
:testClasses
:test

BUILD SUCCESSFUL

Total time: 4.302 secs
Al Jacinto
  • 300
  • 2
  • 7
  • Just to close the loop, I only needed the test.doFirst configs, not any of the other deps. – Allen Apr 23 '15 at 19:19
  • I think I put those dependencies when I was compiling the other projects with JPA. – Al Jacinto Apr 23 '15 at 21:43
  • I'll keep that in mind for later then. Also, could you update your answer to include a little bit about how you observed the Weld container's behavior? How did you see that it was looking in a different dir? What led your investigation down that path? etc. – Allen Apr 23 '15 at 21:58
0

gradle copies the test resources in a different folder than the Weld Container is expecting it to be located. Gradle puts it in build/resources/test/META-INF, the Weld Container the test is using wants it to be in build/classes/test/META-INF. You can copy it manually:

test.doFirst {
 copy { 
   from 'build/resources/test/META-INF/beans.xml'
   into 'build/classes/test/META-INF'
 }
}

Maven does it differently, if you run mvn test, you can see target/test-classes/META-INF/beans.xml

Al Jacinto
  • 300
  • 2
  • 7
  • Adding that code to the gradle.build produces the exact same behavior as I described before. – Allen Apr 23 '15 at 15:46