Re: Current state of one .js file per module
If Eclipse is your IDE you can also use the SDBG plugin to debug in Eclipse. https://sdbg.github.io/ If IntelliJ is your IDE, there is support there as well, but not sure how it works. On Saturday, December 6, 2014 11:39:59 AM UTC-7, Luis Fernando Planella Gonzalez wrote: Ok, I'll try to use separated servers for code server and server side. Regarding the monolithic .js, in GWT 1.6 it was impossible to debug in both Chrome and Firefox - they both crashed, and I always suspected that the js / sourcemap file were too big. Now with GWT 2.7 I can debug normally in Chrome (didn't try in Firefox yet). Still I guess it could be faster to debug using separated .js files. However, as this is no longer GWT's goal, ok. At least now debugging in Chrome is usable, and I no longer need that old version of Firefox 26 which still runs the classic dev mode. Em sexta-feira, 5 de dezembro de 2014 12h31min41s UTC-2, Jens escreveu: Separate compilation mentioned in your linked issue has been reworked into incremental per file compilation what you have now with GWT 2.7. The benefit is that people do not have to refactor their applications into multiple modules to get the benefit of faster recompiles in SDM. Regarding CodeServer restarts: With current GWT master branch, a restart of the CodeServer reuses the caches from the last compile which reduces the startup time of CodeServer significantly. Keep in mind that you do not have to use the DevMode class to start the embedded Jetty + Code Server process. You can also split these processes so you do not have to restart SDM CodeServer if you do a server side change. DevMode -noserver or launching CodeServer directly only starts the SDM code server. Then you can provide your own application server or actually start DevMode -nosuperdevmode which does start classic DevMode but also the embedded Jetty for your server side code. I rarely restart CodeServer during the work day. -- J. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Current state of one .js file per module
Ok, I'll try to use separated servers for code server and server side. Regarding the monolithic .js, in GWT 1.6 it was impossible to debug in both Chrome and Firefox - they both crashed, and I always suspected that the js / sourcemap file were too big. Now with GWT 2.7 I can debug normally in Chrome (didn't try in Firefox yet). Still I guess it could be faster to debug using separated .js files. However, as this is no longer GWT's goal, ok. At least now debugging in Chrome is usable, and I no longer need that old version of Firefox 26 which still runs the classic dev mode. Em sexta-feira, 5 de dezembro de 2014 12h31min41s UTC-2, Jens escreveu: Separate compilation mentioned in your linked issue has been reworked into incremental per file compilation what you have now with GWT 2.7. The benefit is that people do not have to refactor their applications into multiple modules to get the benefit of faster recompiles in SDM. Regarding CodeServer restarts: With current GWT master branch, a restart of the CodeServer reuses the caches from the last compile which reduces the startup time of CodeServer significantly. Keep in mind that you do not have to use the DevMode class to start the embedded Jetty + Code Server process. You can also split these processes so you do not have to restart SDM CodeServer if you do a server side change. DevMode -noserver or launching CodeServer directly only starts the SDM code server. Then you can provide your own application server or actually start DevMode -nosuperdevmode which does start classic DevMode but also the embedded Jetty for your server side code. I rarely restart CodeServer during the work day. -- J. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Current state of one .js file per module
Hi. I created an issue several months ago - https://code.google.com/p/google-web-toolkit/issues/detail?id=8581[1] to split up generated .js. The answer was that a .js file, with its corresponding source map, would be generated per module. I'm analyzing now (with GWT 2.7.0) the output, and I still have 1 single monolithic, .js file and a single source map. Has this subject been aborted, postponed, or just not enabled by default? My project is big. It would be great if the files were split per module, as commented in the issue. I'd love to improve this, and reduce the timings on it. Specially between runs - sometimes small incompatible debug changes in server side forces a restart - and a new compilation. In this case, the reload button doesn't help, as the JVM is inconsistent anyway. Just for the record, here's the compilation log for the project (the real module was changed to package.Project). GET /recompile/project Job package.Project_1_0 starting job: package.Project_1_0 binding: user.agent=safari Compiling module package.Project Unification traversed 99049 fields and methods and 8257 types. 8223 are considered part of the current module and 8223 had all of their fields and methods traversed. Compiling 1 permutation Compiling permutation 0... Linking per-type JS with 8207 new types. prelink JS size = 21670288 prelink sourcemap = 21670288 bytes and 461483 lines postlink JS size = 21503531 postlink sourcemap = 21503531 bytes and 458742 lines Source Maps Enabled Compile of permutations succeeded Compilation succeeded -- 87,370s Linking into /tmp/gwt-codeserver-6688054585701610251.tmp/package.Project/compile-2/war/project; Writing extras to /tmp/gwt-codeserver-6688054585701610251.tmp/package.Project/compile-2/extras/project Link succeeded Linking succeeded -- 2,417s 90,304s total -- Compile completed [1] https://code.google.com/p/google-web-toolkit/issues/detail?id=8581 -- You received this message because you are subscribed to the Google Groups Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Current state of one .js file per module
Separate compilation mentioned in your linked issue has been reworked into incremental per file compilation what you have now with GWT 2.7. The benefit is that people do not have to refactor their applications into multiple modules to get the benefit of faster recompiles in SDM. Regarding CodeServer restarts: With current GWT master branch, a restart of the CodeServer reuses the caches from the last compile which reduces the startup time of CodeServer significantly. Keep in mind that you do not have to use the DevMode class to start the embedded Jetty + Code Server process. You can also split these processes so you do not have to restart SDM CodeServer if you do a server side change. DevMode -noserver or launching CodeServer directly only starts the SDM code server. Then you can provide your own application server or actually start DevMode -nosuperdevmode which does start classic DevMode but also the embedded Jetty for your server side code. I rarely restart CodeServer during the work day. -- J. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.