How make a groovy script with unit tests available to gradles test phase classpath?

(Jay Vyas) #1

I have a gradle project which simply runs some unit tests. However, gradle doesn’t compile these groovy scripts into the classpath.

Thus, the unit tests fail with classnotfound errors.

How can i ensure that the sourceSets are compiled and on the classpath in the groovy test goal?

sourceSets {

test {

groovy {

srcDirs = [’/opt/bigtop/bigtop-tests/test-artifacts/hadoop/src/main/groovy/’]

exclude ‘org/apache/bigtop/itest/hadoop/hdfs/**’

exclude ‘org/apache/bigtop/itest/hadoop/hcfs/**’

exclude ‘org/apache/bigtop/itest/hadoop/yarn/**’


(Peter Niederwieser) #2

If you apply the ‘groovy’ plugin, and put the scripts in the correct Groovy source dir, they will get compiled as classes with class name corresponding to script (file) name, and will be visible to tests.

(Jay Vyas) #3

Thanks for the answer, but the contrary appears to be occuring: actually, that the script is found: But it is not available to the test phase. Are there any ideas on why this could be the case ? Thanks!

org.apache.bigtop.itest.hadoop.mapreduce.TestHadoopExamples > classMethod FAILED Class TestHadoopExamples doesn’t belong to any jar file in the classpath

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(

at java.lang.reflect.Constructor.newInstance(

at org.codehaus.groovy.reflection.CachedConstructor.invoke(

at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(

at org.apache.bigtop.itest.JarContent.unpackJarContainer(JarContent.groovy:180)

at org.apache.bigtop.itest.JarContent$ Source)

at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(

at org.apache.bigtop.itest.JarContent$ Source)

(Peter Niederwieser) #4

Sounds like the party that is throwing this exception expects to find the class file inside a Jar file, rather than inside a classes directory such as ‘build/classes/main’. You can achieve this with something like ‘sourceSets.test.runtimeClasspath += jar.outputs.files’ (provided the classes are contained in the Jar generated by the ‘jar’ task).

(Jay Vyas) #5

Thanks thats a good point: There are some snippets in my groovy script which are specifically looking to the jar resource.

the .outputs.files notation seems very magical to me. can you clarify how it works and how one would utilize it without poking around in the blind?

(Peter Niederwieser) #6

For any task ‘foo’, ‘foo.outputs.files’ refers to the files produced by that task. This works for all tasks that declare their outputs (otherwise you’d get an empty collection). Typically, outputs are declared by the task class, rather than by each task individually.