Gradle web projects with javax.servlet dependency lead to errors on server

Details

Description

We are in the process of writing an application (for a Spring MVC/Web Flow book) and we use Gradle as our build tool. We hoped to be able to use the Gradle support build-in STS. However strange things happen.

We have a multi module project and each web project has 'org.glassfish:javax.servlet:3.0' and 'org.glassfish:javax.servlet.jsp:3.0' as a providedCompile dependency for the web app. If we now deploy this application to the tc server shipped with STS (or an freshly installed tomcat) we get errors as soon as a page is being displayed.

We get LinkageErrors on the classes from the javax.servlet package. It appears as if the jars get deployed with the application and also loaded.

The strange thing is if we use the eclipse plugin from gradle (gradlew cleanEclipse eclipse) it works like a charm, but using the plugin from STS we constantly get these exceptions.

This seems like a very similar problem to yours. Though I did put something in that should address it... it is possible that your project or method of deployment etc. isn't quite covered by the fix. (I can't tell, because there is not enough information in your bug report to try to reproduce the problem).

In any case, I think it is likely that the problem has something todo with dependencies being doubly deployed (once available from the server itself, and once from your web application). So you may be able to fix it by tweaking the "Gradle Dependencies Deployment Exclusions" configured via "Windows >> Preferences >> Gradle >> WTP".

If you'd like a proper fix (I imagine you do), please vote on GRADLE-1777

I'm keeping the bug open for now, but if you want me to look into it deeper, I'd need more info from you.
Ideally, I'd like a sample project and some detailed steps on how to reproduce the problem with that sample.

Kris De Volder (c)
added a comment - 10/Jan/12 12:54 PM Please have a look at this bug report.
https://issuetracker.springsource.com/browse/STS-2063
This seems like a very similar problem to yours. Though I did put something in that should address it... it is possible that your project or method of deployment etc. isn't quite covered by the fix. (I can't tell, because there is not enough information in your bug report to try to reproduce the problem).
In any case, I think it is likely that the problem has something todo with dependencies being doubly deployed (once available from the server itself, and once from your web application). So you may be able to fix it by tweaking the "Gradle Dependencies Deployment Exclusions" configured via "Windows >> Preferences >> Gradle >> WTP".
This isn't a nice solution, but it is the best that I can do unless Gradle guys resolve this issue:
http://issues.gradle.org/browse/GRADLE-1777
If you'd like a proper fix (I imagine you do), please vote on GRADLE-1777
I'm keeping the bug open for now, but if you want me to look into it deeper, I'd need more info from you.
Ideally, I'd like a sample project and some detailed steps on how to reproduce the problem with that sample.

> The strange thing is if we use the eclipse plugin from gradle (gradlew cleanEclipse eclipse) it works like a charm, but using the plugin from STS we constantly get these exceptions.

This is somewhat expected. The tooling API is not providing enough information to properly configure the deployment assembly. So the dependencies inside the 'Gradle Dependencies' classpath container will all be deployed, even those that shouldn't be deployed because they are 'provided' by the server.

Kris De Volder (c)
added a comment - 10/Jan/12 1:01 PM > The strange thing is if we use the eclipse plugin from gradle (gradlew cleanEclipse eclipse) it works like a charm, but using the plugin from STS we constantly get these exceptions.
This is somewhat expected. The tooling API is not providing enough information to properly configure the deployment assembly. So the dependencies inside the 'Gradle Dependencies' classpath container will all be deployed, even those that shouldn't be deployed because they are 'provided' by the server.

PS: If you can fix your problem by adding some jar patterns to the 'excludes' list in the Gradle WTP preferences page, please let me know. It may be useful to add this exclusion as a default for the next release of STS.

Kris De Volder (c)
added a comment - 10/Jan/12 1:04 PM PS: If you can fix your problem by adding some jar patterns to the 'excludes' list in the Gradle WTP preferences page, please let me know. It may be useful to add this exclusion as a default for the next release of STS.

As mentioned we use the javax.servlet dependency from glass fish (those are the servlet 3.0 api jars available in the central maven repo). So I added javax.servlet.*\.jar as an exclusion which seems to solve the issue.

However I still think this is a workaround instead of an actual solution. Would be nice if GRADLE-1777 would be fixed by the Gradle Team.

Marten Deinum
added a comment - 11/Jan/12 12:40 AM As mentioned we use the javax.servlet dependency from glass fish (those are the servlet 3.0 api jars available in the central maven repo). So I added javax.servlet.*\.jar as an exclusion which seems to solve the issue.
However I still think this is a workaround instead of an actual solution. Would be nice if GRADLE-1777 would be fixed by the Gradle Team.

Kris De Volder (c)
added a comment - 11/Jan/12 9:41 AM Thanks for confirming this. I will add "javax.servlet.*\.jar" to the default exclusions list.
> However I still think this is a workaround instead of an actual solution. Would be nice if GRADLE-1777 would be fixed by the Gradle Team.
I agree. A correct solution shouldn't have to use a list of regexp to do this but use the fact that a dependency is 'provided' instead. So I hope you put a vote on Gradle-1777
I'll close this ticket. But I've opened a new ticket ( STS-2380 ) to track the work I need to do once Gradle-1777 gets resolved.
Thanks again for reporting the issue.