"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. There are other libs which are bundled in GWT jars, causing some inconveniences too, like 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. 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.
Em sexta-feira, 16 de outubro de 2015 06:13:38 UTC-3, Thomas Broyer escreveu: > > > On Thursday, October 15, 2015 at 9:25:40 PM UTC+2, bendg25 wrote: >> >> Can you ditch the embedded Jetty server please. >> > > Hmm, no. But it'd be interesting to know the reason for that request. > For example, a 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, and the part of your application that would need Jetty > is likely its server side. So the answer in such case is to "just" use > different classpaths/build paths for the client and server sides. > -- 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+unsubscr...@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.
