[GRADLE-1128] ClassNotFoundException (StringUtils) when running any JUnit test on Gentoo Linux Created: 24/Aug/10  Updated: 04/Jan/13  Resolved: 27/Jan/11

Status: Resolved
Project: Gradle
Affects Version/s: 0.9
Fix Version/s: 1.0-milestone-1

Type: Bug
Reporter: Assaf Berg Assignee: Peter Niederwieser
Resolution: Cannot Reproduce Votes: 0


 Description   

I've upgraded from gradle 0.8 to 0.9-rc1 and something must have changed in the way a new JVM is forked because as soon as I add a JUnit or TestNG class I get an exception.
This seems to be a problem with my environment (Gentoo Linux) since it works fine in windows, but it worked on both platforms in 0.8.
I tried to debug the problem but it happens in the initialization of the forked VM (setting up logging) before even running any test.

I feel this has something to do with my setup, but I'm a little stuck in debugging it and I didn't receive any response in the mailing list.

The exception trace is:
java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
at org.gradle.logging.AnsiConsole$LabelImpl.draw(AnsiConsole.java:178)
at org.gradle.logging.AnsiConsole$1.execute(AnsiConsole.java:51)
at org.gradle.logging.AnsiConsole$1.execute(AnsiConsole.java:48)
at org.gradle.logging.AnsiConsole.render(AnsiConsole.java:65)
at org.gradle.logging.AnsiConsole.addStatusBar(AnsiConsole.java:48)
at org.gradle.logging.ConsoleBackedFormatter.<init>(ConsoleBackedFormatter.java:33)
at org.gradle.logging.Slf4jLoggingConfigurer.configure(Slf4jLoggingConfigurer.java:100)
at org.gradle.logging.DefaultLoggingConfigurer.configure(DefaultLoggingConfigurer.java:34)
at org.gradle.logging.LoggingSystemAdapter.setLevel(LoggingSystemAdapter.java:55)
at org.gradle.logging.LoggingSystemAdapter.on(LoggingSystemAdapter.java:42)
at org.gradle.logging.DefaultLoggingManager$StartableLoggingSystem.start(DefaultLoggingManager.java:154)
at org.gradle.logging.DefaultLoggingManager.start(DefaultLoggingManager.java:56)
at org.gradle.logging.DefaultLoggingManager.start(DefaultLoggingManager.java:31)
at org.gradle.process.internal.child.ImplementationClassLoaderWorker.execute(ImplementationClassLoaderWorker.java:53)
at org.gradle.process.internal.child.ImplementationClassLoaderWorker.execute(ImplementationClassLoaderWorker.java:36)
at org.gradle.process.internal.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:56)
at org.gradle.process.internal.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:38)
at org.gradle.process.internal.launcher.BootstrapClassLoaderWorker.call(BootstrapClassLoaderWorker.java:52)
at org.gradle.process.internal.launcher.BootstrapClassLoaderWorker.call(BootstrapClassLoaderWorker.java:33)
at org.gradle.process.internal.launcher.GradleWorkerMain.run(GradleWorkerMain.java:30)
at org.gradle.process.internal.launcher.GradleWorkerMain.main(GradleWorkerMain.java:35)



 Comments   
Comment by Assaf Berg [ 27/Aug/10 ]

I found a workaround!

I added the following to the build.gradle script and the problem went away:
test.bootstrapClasspath('/opt/sun-jdk-1.6.0.20/jre/lib/rt.jar')
test.bootstrapClasspath('/usr/share/gradle-bin/lib/commons-lang-2.5.jar')

http://assaf-tech.blogspot.com/2010/07/gradle-ebuild.html

Comment by Adam Murdoch [ 06/Sep/10 ]

Are you using 32 or 64 bit Gentoo? What about the jdk?

Comment by Assaf Berg [ 26/Sep/10 ]

Sorry for the late response, I was on vacation.

I'm using 32 bit gentoo and jdk.

Comment by Assaf Berg [ 27/Jan/11 ]

I'm now on 0.9.2 (gentoo 64 bit and sun-jdk 1.6.0.22) and this does not reproduce.

Comment by Peter Niederwieser [ 27/Jan/11 ]

Please reopen this issue (or create a new one) if you encounter this problem again.

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