The Issue

Running tests with Mule sometimes throws a ClassNotFoundException when it tries to lookup org.apache.commons.cli.ParseException. The following is the whole stack trace. If you’re encountering this, then this blog post is for you!

java.lang.NoClassDefFoundError: org/apache/commons/cli/ParseException
	at org.mule.tck.junit4.AbstractMuleTestCase.<clinit>(AbstractMuleTestCase.java:70)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.cli.ParseException
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)

The problem stems from the commons-cli-1.2 JAR file that’s installed by Studio when running the populate_m2_repo script. The aim of this script is to install several Mule JARs in your local Maven repository so that you do not need to download them during one of your build processes. This is what is shown in the logs when running the populate_m2_repo script from inside Studio:

[INFO] Installing /Users/justin/Downloads/AnypointStudio/plugins/org.mule.tooling.server.3.5.0.ee_3.5.0.201404290129/mule/lib/boot/commons-cli-1.2.jar to /Users/justin/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar

However, a few lines down, we get the following:

[INFO] Installing /Users/justin/Downloads/AnypointStudio/plugins/org.mule.tooling.server.3.5.0.ee_3.5.0.201404290129/mule/lib/opt/groovy-all-1.8.6.jar to /Users/justin/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar

As you can see, the groovy-all JAR is overwriting the commons-cli JAR, resulting in a ClassNotFoundException.

The Fix

As a current workaround, remove the commons-cli-1.2 JAR file from your repository and run the Maven build process again. Maven will then download the correct commons-cli JAR from the central repository and your build should carry on without any problems. To verify whether you have the correct file, the real commons-cli JAR is only a few kilobytes in size. The incorrect commons-cli JAR (which really is groovy-all-1.8.6) is around 6.2 MB.

Why does this happen?

Opening up groovy-all-1.8.6.jar and searching for files called “pom.xml” results in only one file – that of commons-cli. The populate_m2_repo script is picking up this pom.xml file and subsequently overwrites the Apache Commons CLI JAR. It seems the Groovy guys are not packaging their own pom.xml with the groovy-all JAR, even though the real pom.xml can be found in the Central Maven Repository . This issue seems to remain in the latest nightly build of Groovy…

Hope this clears up any confusion you may have!