Aw thanks Thomas, I feel guilty to take so much of your time.

I did just figure out the -war option but ran into another issue... I am 
running the jetty server from Intellij and the CodeServer with the no 
server and war options as suggested. However when it comes to updating the 
code (which it does ;-)) it gets stuck because the jetty server seems to be 
locking the directory. I am basically getting a [ERROR] Can't update 
launcher dir message. I guess this is something to do with Intellij and I 
need to look into it a bit more. I just mention it in case someone has had 
the issue before and is sympathizing with my problems ;-)


On Tuesday, 9 May 2017 15:34:13 UTC+2, Thomas Broyer wrote:
>
>
>
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Reply via email to