[GRADLE-1093] Allow running java plugin test task with a (weaving) system classloader Created: 05/Aug/10  Updated: 04/Jan/13  Resolved: 02/Apr/12

Status: Resolved
Project: Gradle
Affects Version/s: 0.8
Fix Version/s: 1.0-rc-1

Type: Improvement
Reporter: Magnus Rundberget Assignee: Daz DeBoer
Resolution: Fixed Votes: 27


 Description   

It would be really nice it the test task supported running with a custom system classloader. A typical use case would be the need to run tests with a WeavingURLClassLoader (aspectJ).

example:
dependencies

{ testCompile ArtifactContainingCustomClassLoader, artifactX, artifactY }

test

{ systemProperties 'java.system.class.loader':'com.mycompany.system.test.MyWeavingURLClassLoader' }

results in
"Error occurred during initialization of VM
java.lang.Error: java.lang.ClassNotFoundException: com.mycompany.system.test.MyWeavingURLClassLoader"

Comment from Adam;
"The way the test process is implemented means this won't work, as the project's classes aren't available on the system classpath when the jvm tries to instantiate the system classloader. There's no particular reason that this has to be the case, and we could certainly shuffle things around so that the classes are available."

Below a more detailed example of a custom test task to illustrate what would be nice to achieve with the gradle supplied test task;

build.gradle:
task testJunitJava(type: JavaExec) {
testReportsDir = new File(buildDir, "reports/tests")
doFirst

{ testReportsDir.mkdirs() }

classpath = configurations.antJunitTest //classpath with required ant artifacts
main = "org.apache.tools.ant.Main"
args = ["-buildfile", new File(projectDir, "build-tests-ltw.xml")]
systemProperties("test.classpath":configurations.testCompile.asPath,
"target.test.aspects":new File(buildDir, "classes/test-aspects"),
"target.test.reports":testReportsDir
)
}

build-tests-ltw.xml (ant build file)
<project name="external-unittest" default="test" basedir=".">
<target name="test">
<!-- Defaults. Can be overridden on the command line -->
<property name="maven.test.include" value="**/*TestCase.class"/>
<property name="maven.test.exclude" value=""/>
<property name="weaving.class.loader" value="com.telenor.cosmos.system.test.CosmosWeavingURLClassLoader"/>

<junit printsummary="true" haltonfailure="no" fork="yes" forkmode="perBatch">
<jvmarg value="-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl"/>
<jvmarg value="-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl"/>
<jvmarg value="-Djava.system.class.loader=${weaving.class.loader}"/>
<jvmarg value="-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl"/>
<jvmarg value="-Xmx768m"/>
<jvmarg value="-XX:MaxPermSize=192m"/>
<classpath>
<pathelement path="${java.class.path}"/>
<pathelement path="${test.classpath}"/>
<pathelement path="c:\dev\tools\apache-ant-1.8.1\libs17\ant-junit.jar"/>
<pathelement path="target/classes/test-aspects"/>
<pathelement path="target/classes/test"/>
<pathelement path="target/classes/main"/>
</classpath>

<formatter type="xml"/>

<batchtest todir="${target.test.reports}" failureproperty="junit.failure">
<fileset dir="target/classes/test" includes="${maven.test.include}" excludes="${maven.test.exclude}"/>
</batchtest>
</junit>

<antcall target="writeJunitIfSet"/>
<antcall target="writeJunitIfNotSet"/>
</target>

<target name="writeJunitIfSet" if="junit.failure">
<echo file="target/junit.tmp" append="false">junit.failure=${junit.failure}
</echo>
</target>

<target name="writeJunitIfNotSet" unless="junit.failure">
<echo file="target/junit.tmp" append="false">#All tests passed
</echo>
</target>

</project>



 Comments   
Comment by Steinar Haugen [ 15/Aug/11 ]

Why has fix version for this issue changed from "1.0" to "someday"? The issue is (currently) 3rd in the list of unresolved issues, when sorting on "number of votes", so I expected it to get a high priority. Are the votes completely disregarded?

We have an insufficient work-around for this, implementing our own test task using ant. The reason we consider this as an insufficient work-around, is that this differs from the rest of the build; e.g producing different reports, plugins that rely on the test task (like the cobertura plugin) don't work.

Comment by Steinar Haugen [ 10/Nov/11 ]

And now fix version is back to "1.0" again. Thanks.

Comment by Daz DeBoer [ 24/Mar/12 ]

We now launch the test process with all application jars on the classpath, rather than adding them dynamically at a later point. I've added an integration test that sets a custom ClassLoader for java.system.class.loader when running the tests, and this is now working ok.

Please check with the latest nightly release if this issue is fixed for you.

Generated at Wed Jun 30 11:46:44 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.