+1 to removing JettyLauncher but not Jetty entirely, it would still be required by "codeserver" in "DevMode". Remember, there is no intention to retire DevMode as a whole, only the JettyLauncher.
Regarding ServiceLoader, service name collisions and other side effects are not impossible but only if conventions are not honored, besides the explicit "-server" option will always be present. Regarding launcher implementations, I will be providing and maintaining a few, including JettyLauncher replacements, some of which we can choose to make official. On Thursday, 6 March 2025 at 11:52:21 UTC Thomas Broyer wrote: +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/84cd84e3-ebea-4ecc-a0d3-9d8379229429n%40googlegroups.com.
