Thymyleaf + Gradle + Jetty

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Thymyleaf + Gradle + Jetty

Nadav
Hi -

I'm currently evaluating different template engines for a new application, with Thymeleaf being one of the strongest contenders.

Unfortunately it seems like there's a problem with Thymeleaf on Gradle using the JettyRun task. Others have encounters this as well: http://forums.gradle.org/gradle/topics/gradle_classloader_problems_with_jetty_plugin

Any change anybody managed to solve this issue?

Thanks,

Nadav


Reply | Threaded
Open this post in threaded view
|

Re: Thymyleaf + Gradle + Jetty

Emanuel
Administrator
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.
Reply | Threaded
Open this post in threaded view
|

Re: Thymyleaf + Gradle + Jetty

Emanuel
Administrator
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:

dependencies {
  compile 'org.thymeleaf:thymeleaf:2.0.8'
  providedCompile 'javax.servlet:servlet-api:2.5'
}

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:

dependencies {
  compile 'org.thymeleaf:thymeleaf:2.0.8'
  providedCompile (
    'javax.servlet:servlet-api:2.5',
    'xerces:xercesImpl:2.10.0',
    'net.sourceforge.nekohtml:nekohtml:1.9.15'
  )
}

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.
Reply | Threaded
Open this post in threaded view
|

Re: Thymyleaf + Gradle + Jetty

danielfernandez
Administrator
Hi,

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?

Regards,
Daniel.
Reply | Threaded
Open this post in threaded view
|

Re: Thymyleaf + Gradle + Jetty

Emanuel
Administrator
That seems to have fixed it for the example I put together - even works for the jettyRunWar task.
Reply | Threaded
Open this post in threaded view
|

Re: Thymyleaf + Gradle + Jetty

Nadav
Great, thanks for helping!
Reply | Threaded
Open this post in threaded view
|

Re: Thymyleaf + Gradle + Jetty

danielfernandez
Administrator
That's great to know. This fix will be a part of version 2.0.11, therefore.

Regards,
Daniel.
Reply | Threaded
Open this post in threaded view
|

Re: Thymyleaf + Gradle + Jetty

danielfernandez
Administrator
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.


Regards,
Daniel.