Discrepancy in JARs from Maven repos vs gwtproject.org website

[Moshe]

Hello again,

I noticed that there are differences in the packages in gwt-user.jar version 2.11.0 I downloaded from the gwtproject.org vs the jars that I found on Maven repos like mvnrepository.com. The one I downloaded from gwtproject.org contains the packages java.servlet, jsinterop while the other one from maven, does not.

We have code that compiles with the first JAR because it imports javax.servlet.http.HttpSession but fails with the second since it doesn't contains the classes. HttpSession would be provided at runtime by the container, but in the IDE so far we don't container libs in our project from the Tomcat container so we we relied on the GWT JAR having those classes and it sort of worked. 

I'm not sure which GWT jar is the correct one. I haven't checked any of the others for differences. Should I add libs for Tomcat container or should I use the GWT jar that has javax.servlet?

Our dependencies are pulled in from Artifactory. To upload the jars to Artifactory, I have to create a zip bundle artifact. We have a Gradle script that uses ArtifactoryBundles plugin. As such, jars are fetched from online maven repos, the ones that don't have the same package as the one I downloaded manually. 

If javax.servlet has been removed, then fine. I would add libs for Tomcat. But I would like to know why the differences. 

[Colin Alworth]

Quoting (and bolding) from my earlier response, as I wasn't fully clear:

> If you downloaded the 2.11.0 zip, those are 2.11.0 jars in there. The current build process first produces the jars for the zip artifact, and then repackages those for release to maven central, so there will be differences (artifacts in the zip have most dependencies shaded into them, while the ones in Maven Central reference external dependencies were possible to keep the jar size down and allow downstream projects to manage versions as desired).

If you are using maven artifacts, there is an assumption that you want to use maven for your dependencies, and by delegating to other existing maven artifacts, you are able to manage your own versions where desired, and we can deploy smaller jars.

However, you're also hitting another misunderstanding - you should not be using gwt-user in your server classpath (nor gwt-dev). GWT requires no jars at all to be on your server classpath, but you may optionally add gwt-servlet.jar or requestfactory-server.jar as desired.

The gwt-dev jar is the compiler and other build-time tools. It does not belong on your server classpath either, but should only be used when building, running tests, or doing development work (DevMode or CodeServer).

The gwt-user jar consists of classes that will be used in your own client code - this is the bulk of the "not-in gwt-dev" classes that can be found in the GWT repo. This is expected to be provided as input to GWT tests, compilation, or development work, but is only suited for those cases. It may contain some dependencies required to run tests (such as javax.servlet) or facilitate legacy dev mode (org.json), etc.

The gwt-servlet jar in turn is the subset of gwt-user that may be used on your server, for RPC, RequestFactory, and some other features like stack trace deobfuscation. This is explicitly intended to be deployed to servlet containers or other servers (hence the name), and must not contain classes that could conflict in this way. A sub-point to this: gwt-servlet-jakarta.jar is the variant of gwt-servlet.jar that is intended for use in a jakarta.servlet environment. As gwt-user and gwt-dev are never meant to be deployed to the server, they have no such jakarta variant (while requestfactory-server, also explicitly intended for running on the server, does have a requestfactory-server-jakarta.jar variant as well).

As such, as long as you separate your classpaths, you will never have gwt-user in your server classpath, and will not need to tinker on GWT's behalf with your servlet container's libraries. 

For your own artifactory, you are of course free to rewrite the jars as you see fit, and make changes to your tomcat installation, so what follows is how GWT is intended to be used: you should deploy at least gwt-dev, gwt-user, and gwt-servlet-jakarta as-is to your internal artifactory, and only reference gwt-user from client projects, gwt-dev when building/testing, and gwt-servlet-jakarta from jakarta-servlet app servers like tomcat.

[Moshe]

Thanks Colin.

That helps a lot. I need to to include compile dependencies to Gradle build for Tomcat Servlet API.

Previously we uploaded to Artifactory the jars included in the manual download. That's how come we to relying on the servlet api classes in the user jar for development (but not in the deployed app).