Re: gwt-dev classpath pollution

On Tuesday, October 27, 2015 at 9:12:25 AM UTC+1, P.G.Taboada wrote:

Hi there,

gwt-dev ist getting more and more a problem. 

It is packaging a lot of things and putting all of it into development classpath: commons-logging, old servlet api, etc.

I have read a few statements here and there, but I am afraid 2.8 will come and we still will have lots of outdated stuff stuck in there.

I understand that GWT dev needs all of it - but why don't do a repackage or have those as external dependencies? 

Other libs often offer a "-nodeps" jar.

At the risk of repeating myself:

• this is a known "issue", but we've been floating the idea of replacing the build system for years hoping that it would help us solve it, and we still haven't done anything yet. Feel free to send in patches though.
  
• this is actually a non-issue, because there's little to no reason you'd actually have a conflict. Most cases of classpath conflicts are people putting server-side dependencies in GWT's classpath. There's no reason to do this. You should use separate client and server classpaths; if your tooling (IDE or build tool) comes in the way, then blame that tool and find proper ways to separate the classpaths. I'm not saying GWT couldn't do better (it could, and it should), but it's not really an issue if you follow some rules; this is why it's really low priority (from my PoV at least).
• this is mostly legacy, before GWT was "Maven-friendly" (or more generally "managed dependencies friendly", vs. only providing the SDK as a zip file). The advantage of bundling dependencies (and why it was originally done) was that you only had to add a couple JARs to your classpath (and generally, compile against gwt-user only, and add gwt-dev only to run tests, devmode, or the compiler). With all externalized dependencies, there'd have been rules like "add jetty and all its dependencies for devmode and running tests" (it was actually Tomcat at the time; and it now also applies to SuperDevMode), "add HtmlUnit and all its dependencies for running tests" (and remember that in GWT 1.x there was actually no HtmlUnit, GWT relied on JNI and a native library to use a "real" browser, so you had to have the native library at the appropriate place, and that was used for GWTShell and then HostedMode as well –the tools that preceded DevMode). Back in GWT 1.x, the rules would then have rather been "add all those dependencies for GWTShell/HostedMode or running tests", and you could only use a stripped-down classpath for the compiler – there's actually a target in the Ant build to package a "compiler only" JAR).
  So yes GWT 2.8 will come with the same "shape" as GWT 2.7; and j2cl (GWT 3) will work differently (won't load "user code" from the classpath anymore) and be hopefully better packaged from the start.
• some of those "outdated stuff" are transitive dependencies that can't be updated (IIRC, the only blocker was actually HtmlUnit, and it now has a newer version so we could possibly update), others are just there for ages. In any case, updating those dependencies requires a deep understanding of the dependency graph, which no one current has. Feel free to send in patches (there's one already for HtmlUnit and Jetty IIRC). Repackaging might be possible for some dependencies (feel free to send in patches), externalizing might be possible for others (but not all, and not all our dependencies are available "externally" for dependency managers; we'd likely have to add version constraints so externalizing the dependency wouldn't help much except to make it possible to exclude it altogether).

--
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 google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.