+1 to switching to StaticResourceServer by default and in the long term removing JettyLauncher then Jetty entirely.
I don't have a strong opinion on using ServiceLoader but I tend to dislike "environmental/contextual" behavior (add a JAR to the classpath and "automagically" this entirely changes the behavior) in favor of always being explicit (in this case, that means using the StaticResourceServer unless told otherwise through an explicit -server option; as to whether that would use an fqcn or ServiceLoader to an SPI to get short names, your call; I'd do that in separate steps though: first default to StaticResourceServer, then possibly add short names) +1 to adopting and maintaining official implementations (disclaimer: knowing that I won't maintain them myself, but) not having at least "some" official implementations would likely be a show stopper; maybe only have a couple official implementations though, with limited scope (like nowaday's JettyLauncher), and leave the others as "third parties"? (also makes it easier to "abandon" some when/if hardly anybody uses them and/or they become a burden to maintain; and provide more guarantees for the "official" ones?) On Thursday, February 27, 2025 at 1:34:37 AM UTC+1 Colin Alworth wrote: > 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/72533a08-d9f7-491a-8a21-062459d7e8bcn%40googlegroups.com.
