DevMode with -superDevMode hardcoded -noprecompile

358 views
Skip to first unread message

Brandon Donnelson

unread,
Sep 28, 2014, 4:56:17 AM9/28/14
to google-web-tool...@googlegroups.com
I've been thinking it might be good to be able to turn off noprecompile when using super dev mode. 

I found with dev mode, the resources in the public folder could be added to html page, although with -superDevMode on the resources are not available till the first compile happens and this happens after the web page is requested and if any public resources are included in the web page there will be a 404 until the first compile. DevMode blocks until the compile is done so the pattern of resource inclusion has to change for those using public resources in the html page. 

Anyway do you think -noprecompile should be an option to turn off when running DevMode with SuperDevMode?

Thoughts?

Thanks,
Brandon

Thomas Broyer

unread,
Sep 28, 2014, 6:02:22 AM9/28/14
to google-web-tool...@googlegroups.com

Ray Cromwell

unread,
Sep 28, 2014, 4:06:12 PM9/28/14
to google-web-toolkit-contributors
This was fixed recently I think, where all public resources are copied even if no precompile happens.


--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/65212555-efa9-493c-aead-031566baaf20%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Brandon Donnelson

unread,
Sep 28, 2014, 7:02:43 PM9/28/14
to google-web-tool...@googlegroups.com
Cool that would be nifty. 

I've been testing with GWT 2.7.0-SNAPSHOT and GWT 2.6.1, although I haven't noticed those resources getting copied, although maybe its so new the snapshot doesn't have it yet. 

On Sunday, September 28, 2014 1:06:12 PM UTC-7, Ray Cromwell wrote:
This was fixed recently I think, where all public resources are copied even if no precompile happens.

On Sun, Sep 28, 2014 at 3:02 AM, Thomas Broyer <t.br...@gmail.com> wrote:
I'd rather say DevMode's -superDevMode should share the same behavior as https://gwt-review.googlesource.com/#/c/9137/4/dev/codeserver/java/com/google/gwt/dev/codeserver/Recompiler.java


On Sunday, September 28, 2014 10:56:17 AM UTC+2, Brandon Donnelson wrote:
I've been thinking it might be good to be able to turn off noprecompile when using super dev mode. 

I found with dev mode, the resources in the public folder could be added to html page, although with -superDevMode on the resources are not available till the first compile happens and this happens after the web page is requested and if any public resources are included in the web page there will be a 404 until the first compile. DevMode blocks until the compile is done so the pattern of resource inclusion has to change for those using public resources in the html page. 

Anyway do you think -noprecompile should be an option to turn off when running DevMode with SuperDevMode?

Thoughts?

Thanks,
Brandon

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

Manuel Carrasco Moñino

unread,
Sep 29, 2014, 4:30:11 AM9/29/14
to google-web-tool...@googlegroups.com
Brandon, out of curiosity, how do you use those static files in your .html? do you use absolute urls like http://codeserver:port/ModuleName/my_asset.css? Because if you use relative paths they dont work in SDM since you have to prepend the getModuleBaseForStaticFiles() path.

IMO, we should use -noprecompile always, because we dont know what permutation is going to be used until the browser hits the codeserver, and it's a bad idea to spend time precompiling for all permutations. Anyway, I agree that all static files should be copied.

For legacy versions of GWT we could consider to make optional that parameter, let's discuss it in the legacy-jar project in github.


To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/0e254f1e-b2c0-46ef-962f-0aa24b52f292%40googlegroups.com.

Thomas Broyer

unread,
Sep 29, 2014, 5:45:31 AM9/29/14
to google-web-tool...@googlegroups.com


On Sunday, September 28, 2014 10:06:12 PM UTC+2, Ray Cromwell wrote:
This was fixed recently I think, where all public resources are copied even if no precompile happens.


That's the change I linked to, but it's copying the resources to the CodeServer's own temporary folder IIUC.
What Brandon is asking for is copying those same files to the folder pointed to by the -war passed to DevMode, hence my suggestion.
 

On Sun, Sep 28, 2014 at 3:02 AM, Thomas Broyer <t.br...@gmail.com> wrote:
I'd rather say DevMode's -superDevMode should share the same behavior as https://gwt-review.googlesource.com/#/c/9137/4/dev/codeserver/java/com/google/gwt/dev/codeserver/Recompiler.java


On Sunday, September 28, 2014 10:56:17 AM UTC+2, Brandon Donnelson wrote:
I've been thinking it might be good to be able to turn off noprecompile when using super dev mode. 

I found with dev mode, the resources in the public folder could be added to html page, although with -superDevMode on the resources are not available till the first compile happens and this happens after the web page is requested and if any public resources are included in the web page there will be a 404 until the first compile. DevMode blocks until the compile is done so the pattern of resource inclusion has to change for those using public resources in the html page. 

Anyway do you think -noprecompile should be an option to turn off when running DevMode with SuperDevMode?

Thoughts?

Thanks,
Brandon

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

Brandon Donnelson

unread,
Sep 29, 2014, 12:32:06 PM9/29/14
to google-web-tool...@googlegroups.com
We had a reset.css included in the public app folder which was used by adding it to the static html header. In this case I just moved it to the gwt xml module so it was available on gwt app initialization. 

Copying the web resources on SDM init would be nifty. I'm not sure what the commit is doing yet, but that looks like it should work just fine.

What I suspect may happen is folks that are used to using DevMode and since its resource are available on running it b/c of the compiler locking up the web request, some will complain of 404 requests.  

I agree, any speed gains are a bonus so I like the noprecompile and let the browser trigger it. DevMode does that but it locks the browser up. 

Thanks,
Brandon

Manuel Carrasco Moñino

unread,
Sep 30, 2014, 2:06:12 AM9/30/14
to google-web-tool...@googlegroups.com
On Mon, Sep 29, 2014 at 6:32 PM, Brandon Donnelson <branfl...@gmail.com> wrote:
We had a reset.css included in the public app folder which was used by adding it to the static html header. In this case I just moved it to the gwt xml module so it was available on gwt app initialization. 

yep, anything from public folder should be prepended by GWT.getModuleBaseForStaticFiles folder, since it's not available in index.html you have to reference css files through gwt.xml.  The patch does not help here.
I don't think it's a good idea to update the war folder with the static files from public folder since the dev mode launcher does not know anything about those files.

 
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/437e1a32-14c9-45de-87a9-7710f4e76fb1%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages