Since before SuperDevMode was first launched, we've been trying to get away from a single-process DevMode in favor of splitting the client and server classpaths. This has been met with resistance by teams who have development workflows that work, and no great benefit to them from changing them. Combine this with our slow update policy for our embedded Jetty version, and you get a lot of frustration.
GWT 2.12 deprecated the default JettyLauncher, and added a new StaticResourceServer to replace it. In the draft PR https://github.com/gwtproject/gwt/pull/10103 we propose now that GWT 2.13 will switch the default to StaticResourceServer, but before falling back to that default will ask a ServiceLoader if there is exactly one ServletContainerLauncher. Additionally, if more than one SCL is available, they may be selected by a short name rather than the fully qualified class name. In conjunction with this change, Elias Balasis has been working on a set of SCL implementations that use Cargo to start the server, either externally, or in an isolated classpath. This draft project can be found at https://bitbucket.org/upperlimit-public/gwt-devmode-server, and we would like to propose adopting it as an official gwtproject repository, and providing snapshots and releases of it. A given project that chooses to use this would then be able to add one of these adapter jars to their project, and when DevMode starts, that server would automatically be launched with their project. Basic tests of this strategy show that it is working - the server can be debugged and have classes hot reloaded, and the client can deploy new JS as needed to each server implementation. We can then accelerate the removal of Jetty from GWT itself, and encourage users to pick one of these official implementations, request/provide missing implementations as needed, or use the base classes to make their own internal implementation. While I don't love encouraging using DevMode in this way, I also don't want to actively make it harder to continue to develop their projects, and this seems like a decent way to both continue to simplify GWT and reduce its dependencies, but also continue to make it possible for projects to upgrade and preserve their development processes. Any thoughts on my PR above, or adopting the linked repository under github.com/gwtproject? -- 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 visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/9e016711-ad3a-493b-97c5-93117e280128n%40googlegroups.com.
