In this case, using a third-party servlet container (Jetty or Tomcat, or 
even a Glassfish or JBoss; Jetty has the advantage over Tomcat of really 
fast hot-deployment: you just have to "touch" an XML context file, with the 
appropriate config; I can't tell for other containers and app servers) and 
running the DevMode in -noserver is not a bad idea (this is what we use for 
almost a year now, and I'd highly recommend it; at least when using 
RequestFactory, it might be an entirely different story with GWT-RPC and 
its serialization policy files). Just configure your servlet container to 
directly load from within your projects (target/classes of your Maven 
modules for the classes, src/main/webapp and target/<final-name> for the 
static files; again, this is really easy with Jetty's extraClasspath).

That way you clearly separate the client, shared and server code, and 
manage their dependencies in a finely grained fashion.

And you can work independently on the client code (launch DevMode in 
-noserver mode against a test server shared by the whole team, possibly 
using continuous deployment) vs. the server code (compile the GWT client 
code once, then restart/refresh your local server at will): I've worked for 
weeks on client code only, and never had to build/deploy/start a local 
servlet container, only launch the DevMode in -noserver mode against our 
test server (which is automatically updated by our Jenkins builds)
FYI, we have 15 or so Maven modules (well, only 10 of them, approximately, 
being dependencies of our GWT app: 4 are "shared" code, one is "client", 
and others are "server" only).

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to