I'm all for the CodeServer being the main entrypoint for SDM launching. Although we need IDEA to get on board and add the launcher too. I do think some of the pain can be taken out of the process when running the code server with another web server/device process. Like Eclipse has server runtimes, which you can automatically work with. I suspect once the kinks get worked out with working with the Code Server and web server/device runtimes, DevMode will decrease in use. I'd really like to have a code server nocache.js implement the -bindAddress as the hostName instead of window.location to really make it effective with external servers, so a proxy doesn't have to be setup and launcherDir can plan the xxx.nocache.js sdm launcher script. For most enterprise operations, I running the baked in jetty web server is not effective and not very flexible but for a few. Anyway, Eclipse is getting upgrades to the code server launcher. The next version will focus on the code server as the main entry point I think. I'll ask for more feedback as that comes together.
On Saturday, August 27, 2016 at 12:38:05 AM UTC-7, Ignacio Baca Moreno-Torres wrote: > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/ab4c6092-2446-47b2-80a1-b668ad8cf010%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
