On Tuesday, May 9, 2017 at 3:18:38 PM UTC+2, Thomas Lefort wrote:
Hi Thomas,Thanks for the reply. Sure I don't expect anyone to fix it for me, just to know if it is a problem my end or if I am trying to do too much with the embedded server indeed.I am happy with running an external server, however, it would be nice if I could get a similar level of debug functionality, ie breakpoint in server code, all the superdev mode feature, etc... Any good step by step manual? I tried the noserver flag (in Intellij) and running a server aside (as per GWT project page instructions) but it doesn't provide the goodies I mentioned previously, for instance, it doesn't update the client when I change it and reload it. To be honest, I can't really see how the magic would happen without some connection between the two. I am probably missing a key element/step :)
Assuming a server setup that correctly reloads (redeploys the webapp) whenever server-side code (and/or resources) changes (this is outside the scope of GWT; same for debugging).
You run CodeServer with launcherDir pointing to a folder served by the server (or DevMode with -noserver, and -war pointing to that same folder), it then generates a *.nocache.js file in the directory (and copies public resources there too).
When you load your page in the browser, the *.nocache.js is loaded and triggers a compilation in the CodeServer.
Whenever you change client-side code, refresh the page in the browser and it'll trigger a recompilation.
Whenever you change server-side code, redeploy the webapp (depending on the setup, this can be entirely automatic, or involve some manual action).
To debug client-side code, use the browser's devtools, or your usual SDM/IDE integration (I never used any, so can't really comment)
When using my gwt-maven-archetypes for example, "mvn tomcat7:run" will automatically redeploy the webapp whenever resources or classes change in target/classes. Most IDEs will happily compile your code (automatically on save, or triggered by a keyboard shortcut) into target/classes, which would trigger a redeploy. "mvnDebug tomcat7:run" (or running the Maven goal for debug in your IDE; for example, in Eclipse, Debug As… → Maven… → tomcat7:run) allows you to debug your server-side code. And "mvn gwt:codeserver" launches SDM for the client-side code.
AFAIK, the GWT Eclipse Plugin has some "one click" way of running both a server runtime (configured in Eclipse WTP) and SDM, and I'd assume that Eclipse is smart enough to make redeploying after changes either completely automatic or only a keyboard shortcut / click away.
The "connections" you're talking about are the standard JDWP protocol for connecting to a JVM to debug the server-side code in the server runtime, and SDM with SourceMaps (and possibly a "remote debugging" protocol of your browser if you want IDE integration rather than debugging right in your browser).
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+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment