It would indeed work (most of the time I believe), but then you need to 
make sure to force the GWT compiler to compile your code before deploying, 
because it's really easy to get false positives in the staleness check (if 
the superdevmode stub *.nocache.js modification time is more recent than 
your source files, then compilation would be –erroneously– skipped and 
you'd deploy the stub nocache.js rather than your compiled app).
(oh well, Maven is so “broken” when it comes to incremental builds that 
you'd better to a “mvn clean” anyway, just in case, so… but more 
realistically, having 2 run configurations that use the launcherDir or not 
makes it easier to switch between using the compiled app –e.g. when you 
only work on server-side code– and using –and having to launch– 
superdevmode)

As always, do what works best for you (but aware of the strengths and 
drawbacks of each solution)

On Wednesday, March 6, 2019 at 3:13:17 PM UTC+1, Bryan Bende wrote:
>
> I was able to set the launcherDir to server/target/classes/static and that 
> seems to make it work the way I was expecting.
>
> On Tuesday, 5 March 2019 13:55:54 UTC-5, Bryan Bende wrote:
>>
>> Hello,
>>
>> I have a multi-module Maven project setup similar to the multi-module 
>> archetype, but created before I knew about that, using GWT 2.8.2 and the 
>> gwt-maven-plugin 1.0-rc-9.
>>
>> shared - Contains DTOs with JS interop annotations, packaged as gwt-lib
>> client - GWT code, depends on shared as gwt-lib
>> server - spring-boot application which depends on client and shared 
>> modules, packages the nocache.js from client into target/classes/static at 
>> build time, also serves the index.html
>>
>> I launch the application from IntelliJ using a standard run configuration 
>> to start the server, and then a "mvn gwt:codeserver" from the root module 
>> where launcherDir is pointing to 
>> "{project.build.Directory}/gwt/launcherDir" of the root module.
>>
>> The first time I load the application in Chrome it will automatically 
>> compile and then load fine. If I then make a change to something in the 
>> client module and refresh the page, it does not automatically compile. If I 
>> then click the bookmark for "Dev Mode On", it will pop up the dialog and if 
>> I click compile it works fine.
>>
>> I'm trying to figure out what the difference is between the first page 
>> load and the subsequent ones. Looking in Chrome Dev Tools after the first 
>> page load, I can see that some script elements get injected at the top of 
>> the head element related to recompile, but then when I do the next refresh 
>> some of those elements are no longer there, but there is still one element 
>> pointing to the codeserver for the nocache.js.
>>
>> Is there anything obvious that I'm missing preventing the auto-compile on 
>> refresh?
>>
>> One thing I tried was altering the server's locations for static 
>> resources by setting 
>> spring.resources.static-location=file://../target/gwt/launcherDir,classpath:/static/
>>   
>> so that it would load the nocache.js from the launcherDir, but doesn't seem 
>> to really change the behavior. Maybe that part isn't working the way I 
>> think it is.
>>
>> Thanks,
>>
>> Bryan
>>
>>

-- 
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+unsubscr...@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.

Reply via email to