Re: Next release

On Friday, October 16, 2015 at 3:25:04 PM UTC+2, Luis Fernando Planella Gonzalez wrote:

"classpath conflict is generally not a valid reason, because the part of GWT that includes Jetty is not concerned about the server side of the applications"

Unless you run [Super]DevMode, which runs both in a single JVM, then it is a pain.

Well, if you decide to run your server-side code inside the server that ships with DevMode, then you have to deal with the version DevMode works with.

If it causes you trouble, it most likely means you're not building a "portable webapp" (that could run in any servlet container), and in that case you shouldn't use the embedded server.

 

There are other libs which are bundled in GWT jars, causing some inconveniences too, like 

There might be some "leaks" to the webapp (2.6.0 was known to be broken for instance), but as long as your server-side dependencies are not in the DevMode classpath (and only in your webapp's WEB-INF/ ) it should Just Work™ (for "portable webapps"), as they cannot conflict with GWT's own dependencies.

As I said: classpath conflicts are generally not a valid reason.

IMHO, saying to run with -noserver is not a perfect solution either, because it complicates things, requiring 2 jvms, and don't playing well with RPC and security policies.

AFAICT, RPC works well (at least in 2.7, but IIRC even before that); you just have to tell your RemoteServiceServlet to go load the serialization policies from the CodeServer using the gwt.codeserver.port system property: http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/server/rpc/RemoteServiceServlet.html#getCodeServerPolicyUrl(java.lang.String)

Can you give more details about "security policies" ?

 

Having most of people (if not all) using either an IDE plugin or Maven, which can manage the classpath, I don't see a reason to bundle (very old) 3rd party classes in the GTW jar.

I don't necessarily disagree, but version mediation by tools like Maven is not a silver bullet.

Jetty, for instance, has a rather bad record wrt backwards compatibility. Currently, Jetty is used in GWT by the CodeServer to compile your code on the fly and serve it, by DevMode to host your webapp, by GWTTestCase/JUnitShell to serve the test's host page and script, and host servlets (both the ones used by the testing infra and user-provided ones), and by HTMLUnit, used by GWTTestCase/JUnitShell.

As you can see in https://gwt-review.googlesource.com/7857, upgrading Jetty is a breaking change, as is upgrading HTMLUnit. So not bundling them in the JAR wouldn't mean that you could use other versions, and using a tool like Maven could make you use other versions without you necessarily noticing.

Really, the solution is segregating client and server classpaths. GWT 3.0's new "j2cl" transpiler might change things a bit, but still in ways that are largely similar to what exists today (i.e. you won't put your code anymore in the classpath at all, instead you'll pass a classpath to the transpiler just like you give one to javac, and that one might container server-side code that –and that's the change– won't conflict with GWT's internal dependencies)

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