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