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). On Thursday, October 3, 2024 at 5:57:27 PM UTC-7 Colin Alworth wrote: > 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. > > > > On Thursday, October 3, 2024 at 6:43:42 PM UTC-5 [email protected] wrote: > >> 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. >> >> >> -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/cfcd45bf-0abe-4aaa-8824-85d073f0725an%40googlegroups.com.
