I'm suspicious of the Gradle Jetty plugin in this case since I run Thymeleaf on Jetty without any problems. Looking at the link you've provided, and then following it through to the issue on the Gradle issue tracker, the original poster was able to get things to work with either the Jetty runner, or by regressing to Gradle 1.0M3.
I'll get back to you later tonight after trying some stuff out with that plugin.
OK, I did some testing with a simple web app that used Thymeleaf and deployed to Jetty using Gradle and the Jetty plugin. The Gradle docs say the jettyRun task depends on the compile task, and when my compile dependencies just looked like this, then I would get the error you describe:
The Thymeleaf class that shows up in the stack trace has a compile-time dependency on Xerces and Neko. This shouldn't really matter since we're running against a precompiled JAR, but for some reason it does when using the Jetty plugin. So I thought to include Xerces and Neko as compile-time dependencies, but not to include them as part of the exploded WAR that gets used by jettyRun:
And for some strange reason, this worked for me - my test web app ran without the error. Are you able to get passed your error by adding Xerces and Neko as non-included compile-time dependencies as well?
This trick didn't seem to work for the jettyRunWar task though.
I've just added to the nekoHTML checking logic a catch for NoClassDefFoundError (besides ClassNotFoundException). This could allow gradle to check the existence of nekoHTML without failing on the non-existance of Xerces in the classpath.
I've added it to a new 2.0.11-SNAPSHOT snapshot version. I cannot try Gradle myself so... could you please test whether this does work for you?
Oh, and by the way: Anyway I suspect there is a problem with Gradle's Jetty plugin, which is including into your classpath optional dependencies (nekoHTML, in this case), which it shouldn't.
If it weren't so, there would be no way that an attempt to load the NekoHTML class results in trying to load Xerces. Only if that NekoHTML class is actually there, this can happen. And being an optional dependency, if you don't use it in your applicacion there is no reason that class is there.
So it must be this plugin including it into your classpath without a reason.