Skip to end of metadata
Go to start of metadata

Ant Task Troubleshooting

The Common Problem

Very often, the groovy or groovyc tasks fail with a ClassNotFoundException for the class GroovySourceAst.

The Reason

If it's failing with a ClassNotFoundException for a class other than GroovySourceAst, welcome to Ant.  As the Ant manual for external tasks says, " Don't add anything to the CLASSPATH environment variable - this is often the reason for very obscure errors. Use Ant's own mechanisms for adding libraries."  And as its library directories section says, "Ant should work perfectly well with an empty CLASSPATH environment variable, something the the -noclasspath option actually enforces.  We get many more support calls related to classpath problems (especially quoting problems) than we like."  So try running Ant as ant -noclasspath, or even alias ant to that in your shell.

If the class that isn't found is GroovySourceAst and the above doesn't help, somewhere you have a conflicting antlr in your classpath.  This may be because you are using maven and one of this parts is polluting the classpath or you have a different antlr jar in your classpath somewhere.

Solution 1: groovy-all

Use the groovy-all-VERSION.jar from the groovy distribution and not the normal groovy jar. The groovy-all-VERSION.jar does already contain antlr and asm libs in a seperate namespace so there should be no conflict with other libs around.

Solution 2: using loaderref

Sometimes it's not possible to use the groovy-all-VERSION.jar, for example because you want to build groovy before creating the jar. In this case you have to add a loaderref to the task definition. But that alone will not help. You have to add the rootLoaderRef task to set this loader reference. For example:

The groovy task will now be created using the tmp.groovy.groovyc class loader, which tries to avoid loading conflicting jars like antlr. It's important to execute the rootLoaderRef task once before the taskdef using the loaderref defined by the rootLoaderRef.

Solution 3: appropriate classpath set up

You may need to adjust your classpath setup to include the jars you are trying to use. For instance, if you have placed the groovy jar in your Ant LIB folder, then Groovy will be in Ant's root classloader. If you now wish to refer to an external library, e.g. a JDBC driver, you may need to place that library also in your Ant LIB folder so that it is visible in the same classLoader as Groovy. See the loaderref discussion above also.

Also, the Groovy distribution doesn't include the entire Ant distribution. If you are using some optional Ant tasks, you may need to add some additional jars to your classpath to use the additional features. Here is an incomplete list of some Ant tasks which require additional jars:

Ant Task

Additional Jar(s)

junitreport

ant-trax.jar, xercesImpl.jar, xml-apis.jar

mail

mail.jar, activation.jar, smtp.jar (if using SMTP), ant-javamail.jar (if sending MIME email)

sql

your_JDBC_driver

All Solved?

No, both Solutions will not help if you have conflicting ant jars or common-logging jars somewhere. Solution 2 is able to solve much more difficult jar problems as long as your classpath is as clean as possible. if you want to be on the safe side you have to fork the javaVM which means you have to use the task like this:

References

  • No labels

2 Comments

  1. Actually, forking the JVM won't work, because the classpath element will set the classpath used to launch Groovyc, not the classpath that Groovyc uses to compile.  Groovyc creates a separate classloader and compilation configuration with the compiling classpath.  There's no way to set that from the command line, so the forked Groovyc will always compile with a null classpath.

  2. Actually, it turns out that wasn't my problem, and I've managed to get my build going without having to fork at all.  So while the Groovyc task when invoked this way doesn't explicitly add anything to its compile classpath, maybe it inherits it or something.