Em... this is kind of related, some days ago I speak about this with manolo in gitter; currently the CodeServer use the standard nocache.js instead of the compile-on-refresh (actually uses the compile-on-refresh the first time, but subsequent compilations uses the standard one). And... does not makes more sense that the codeserver compilations always uses the compile-on-refresh nocache.js? I think that this is in general quite useful, but is even more useful for client only project so the codeserver serves all the resources (just need to move your index.html into a public folder like this https://github.com/ibaca/rxcanvas-gwt/blob/master/src/main/java/rxcanvas/public/index.html). Hopefully this will promove using codeserver alone even more.
On Friday, August 26, 2016 at 5:34:28 PM UTC+2, JonL wrote: > > I guess I didn't word it correctly. I think I am talking more of the > experience of running the CodeServer and the embedded Jetty Server serving > the app, in one shot utilizing the eclipse plugin has become synonymous in > my head with SDM. Where as running the web app on an external server and > manually starting the CodeServer, I don't so much attribute to being > "super", but more "cumbersome" dev mode. So I guess what I am trying to > say is that from the eclipse development perspective, utilizing the plugin, > there should always be a one shot command that starts up the CodeServer and > deploys the app for you and then maybe you start a browser using SDBG > Plugin, should remain the most cumbersome experience for utilizing the > plugin, by default. > > I don't use the maven plugin, but I would guess by discussion that there > is a similar experience where the maven plugin starts up the codeserver and > uses DevMode plugin for deployment. > > So ultimately, I think, unless there is a better way, across all these > plugins to provide a similar getting started experience where you run one > command to start the CodeServer and a deployment server, my vote, if it > counts for anything, would be to keep c.g.g.dev.DevMode with only SDM and > refactor it possibly so that its clear to what it is and separate it, > cognitively, from the old classic DevMode utilizing the browser plugin. > > On Friday, August 26, 2016 at 7:58:24 AM UTC-7, Thomas Broyer wrote: >> >> >> >> On Friday, August 26, 2016 at 4:30:48 PM UTC+2, JonL wrote: >>> >>> I have always considered the deprecation of "DevMode" to mean the >>> deprecation of the "HostedMode"/GWT Dev Mode plugin combo and that SDM was >>> the non-deprecated version. It sounds like some are considering losing SDM >>> as the default run mode. I think that would be a mistake and would make it >>> appear that GWT is more cumbersome to use than it is. Hosted Mode w./ Dev >>> Mode Plugin was broken due to the deprecation of the NPAPI plugin, other >>> than possibly refactoring out SDM from the DevMode class, I would >>> personally consider removing SDM as breaking something that isn't broken >>> for no particular reason. >>> >> >> I don't understand what you mean. >> >> DevMode can mean either "dev mode using the browser plugin", or "the >> c.g.g.dev.DevMode entrypoint class". >> SDM, to me, can only mean "dev mode using compiled-on-the-fly JS", so >> it'd be the opposite of "dev mode using the browser plugin", without saying >> "how" you run it. >> The opposite of "the c.g.g.dev.DevMode class" is CodeServer (i.e. "the >> c.g.g.dev.codeserver.CodeServer class"). >> And SDM could be used either through c.g.g.dev.DevMode or CodeServer. >> So for SDM, there's no terminology problem, and yet I don't understand >> what you mean by "removing SDM". >> >> CodeServer will stay, that's a given. The question (to the Steering >> Committee) is whether c.g.g.dev.DevMode will stay with only its SDM mode, >> or whether it'll be removed (and SDM can only run through CodeServer, which >> would remain the only "development mode" of GWT). >> > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/80e84a7d-1afa-4d9d-847f-7cd2145571a1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
