On Mon, Mar 17, 2014 at 1:54 AM, Jens <[email protected]> wrote:
> +1 The problem is determining what "provided by the server" actually means >> though. Servers generally just use their classpath, but in our case the >> classpath generally (because of Eclipse, and because of how DevMode loads >> client code too) contains the classes that also are in WEB-INF/lib, so >> delegation to the "server classpath" just won't work (or rather, it'll work >> "too well", and won't detect that "something is missing in WEB-INF/lib". >> >> I've written a memo on the issue, and possible solutions: https://docs. >> google.com/document/d/1bWfafaPA0m0Z1Swodnx7m3QTv31Od >> qFkE7aeadN_2BU/edit?usp=sharing >> > > Wouldn't it be a ton easier to just launch Jetty as a separate process > using ProcessBuilder when DevMode is launched? Of course this new process > should not have DevMode class path. Then its pretty much like -noserver but > users do not have to setup a jetty server themselves. > Relatively easy to do with the GWT SDK (just put a jetty.jar in there and use that as the single entry in a root URLClassLoader, don't even need ProcessBuilder), much less elsewhere (Maven, Gradle, Ivy, etc.). BTW, this is more or less what the AppEngine launcher does currently (IIUC), setting up the classpath from known JARs from the AppEngine SDK. > Also I am curious why r4944 says its too much of a burden to get the class > path right and why the old behavior causes integration problems. If class > path is wrong and GWT "repairs" it, it will fail later in production. I > don't really see the benefit. > As a user, having a big warning that I should move a JAR but can continue to work is probably better than having to restart DevMode (which could be slow, particularly back then). Not all users understand the warning though (as we recently saw in the gwt user forum; link in the memo), so breaking with a good error message would maybe be a better choice in the end. Possibly due to Google Plugin for Eclipse too: Eclipse probably makes it very easy to use the project's build path as the DevMode classpath but maybe difficult to test upfront which JAR should be in WEB-INF/lib; not to mention that the project build path probably mixes client-side and server-side dependencies. IIRC we were also migrating from the Tomcat-based HostedMode where everything was loaded from the classpath (no "war" at all, static resources such as your host page had to come from "public sources" of your module(s), servlets were defined in the gwt.xml). This is only speculation though. > But I have to say that I always use -noserver so maybe I am missing > something. > Same here. I use DevMode's embedded server only for simple projects like issue repro cases; but all my projects are Maven-driven (maybe soon Gradle-driven) so it's very easy to get things correctly setup in WEB-INF/ We're "power users", Jens; I think newbies (people learning all of GWT, java webapps, servlets and even web dev and/or java) can easily mess everything up, because of the steep learning curve. We probably also need to update our docs (particularly start adding things about Maven and Gradle, and how to use them with Eclipse or IntelliJ IDEA –or Netbeans?) . -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
