-whitelist
and-blacklist
are actually never used. They're a left over from the legacy hosted mode which embedded a browser widget (and could control the Same-Origin Policy), rather than being embedded in the browser through a plugin.HostedMode
is currently the same asDevMode
. It only exists for backwards-compatibility (see above)properties files for all your
Messages
andConstants
for all your locales (provided you configured a@Generate
for those) to make it easier to bootstrap I18N, compile report –if you also pass-compileReport
–, CSS maps of obfuscatedCssResource
class names, and logs of GWT-RPC serialization policies (which classes were included/excluded and why).-workDir
is where GWT writes most of it's temporary data (not all, some things go to the OS temporary folder –configurable with the-Djava.io.tmpdir=
system property– or to a.gwt-unitCache
folder –configurable with the-Dgwt.persistentunitcachedir=
system property–). When you do distributed builds, theworkDir
has to be shared by all machines (either shared on the network, or by copying files around).In DevMode, the embedded Jetty server runs your webapp (your server code and your static resources) from the
-war
folder (defaults towar/
in the current directory). The codeserver is what serves your client code. In DevMode, the codeserver uses a raw TCP connection to communicate with the plugin that sits in your browser; in SuperDevMode, the codeserver is a Jetty instance that serves JavaScript compiled (almost) on the fly, it doesn't host your webapp though.See #3 above, and http://www.gwtproject.org/doc/latest/DevGuideCompileReport.html
BTW, the GWT project now has a new home: http://www.gwtproject.org