I could easily write a Main class that runs an embedded Jetty server (https://eclipse.dev/jetty/documentation/jetty-12/programming-guide/index.html#pg-server-http-handler-use-servlet-context) with the configured GWT-RPC servlet and serving static resources from multiple dirs (https://eclipse.dev/jetty/documentation/jetty-12/programming-guide/index.html#pg-server-http-handler-use-resource), but then there would still be a whole lot of questions either unanswered or with an necessarily opinionated answer:
- how to set "dev mode" for the Main class? (to add the codeserver's launcherDir to the resource bases; I would personally use a system property with the launcherDir's path and react to its presence/absence) - how to package/deploy the static resources? as resources in the JAR? (that's what I'd do if I'd wanted my deliverable to be a single JAR) as a directory alongside the JAR? (that's what I'd do if my deliverable were a native deb/rpm/whatever package or a Docker image) - that Main class would likely not be production-ready (should it use the QoSHandler? GzipHandler? how about the CrossOriginHandler? the ForwardedRequestCustomizer <https://eclipse.dev/jetty/javadoc/jetty-12/org/eclipse/jetty/server/ForwardedRequestCustomizer.html> ?) - you'd probably want to refactor the Main class anyway to add command-line arguments and/or configuration files, a logging framework, possibly dependency-injection, etc. My question is: *what do you expect from such an archetype?* The initial goal was to show how to cleanly/clearly separate client/shared/server classpaths, which involves some configuration for how to run the server so it serves the codeserver's launcherDir. As soon as you go "custom" on the server, you have to handle that specific "dev mode" configuration, but then it's custom to your custom code, and necessarily becomes somewhat opinionated. This means that the archetype can't really "show you how to do things" without being opinionated, and I don't want to go that road (I specifically don't want to *maintain* such an opinionated thing). Feel free to create opinionated archetypes though, and I'll happily review them and help you set them up (this will bring my own opinions into the mix though) On Friday, February 23, 2024 at 12:05:22 AM UTC+1 ma...@craig-mitchell.com wrote: > I know it's outside of its scope, but it would be great if > https://github.com/tbroyer/gwt-maven-archetypes had an example of "If you > want to create an executable jar with Jetty, this is how you could do it". > 🙂 > > On Thursday 22 February 2024 at 5:30:51 am UTC+11 Tim Macpherson wrote: > >> I tried starting with the tbroyer archetype & to the server project I >> added the app engine stuff from the Google sample to build the >> appengine-staging dependencies directory. >> Maybe all that should be in a separate project ? >> >> Sent from Yahoo Mail on Android >> <https://mail.onelink.me/107872968?pid=nativeplacement&c=Global_Acquisition_YMktg_315_Internal_EmailSignature&af_sub1=Acquisition&af_sub2=Global_YMktg&af_sub3=&af_sub4=100000604&af_sub5=EmailSignature__Static_> >> >> On Wed, Feb 21, 2024 at 17:42, Thomas Broyer >> <t.br...@gmail.com> wrote: >> >> >> >> On Wednesday, February 21, 2024 at 3:11:54 PM UTC+1 >> tim_mac...@yahoo.co.uk wrote: >> >> I've been trying this app engine sample for Java 11+ which uses a JAR >> packaged artifact that is installed locally: >> it provides a Main class to instantiate an HTTP server to run an embedded >> web application WAR file. >> >> github.com/GoogleCloudPlatform/java-docs-samples/tree/main/appengine-java11/appengine-simple-jetty-main >> It has explicit jetty 11 dependencies. >> >> The WAR project is >> >> github.com/GoogleCloudPlatform/java-docs-samples/tree/master/appengine-java11/helloworld-servlet >> The WAR is run in a local server with: >> mvn exec:java -Dexec.args="../helloworld-servlet/target/helloworld.war" >> >> The problem I have is when I include GWT in the WAR project this draws in >> Jetty 9 & other dependencies >> which get copied to the cloud-deployment dependencies directory. >> >> >> This means you WAR have dependencies on gwt-user and/or gwt-dev, that you >> never want to deploy to a server. The WAR should have a dependency on >> gwt-servlet only (or requestfactory-server). >> >> …and this is exactly what https://github.com/tbroyer/gwt-maven-archetypes >> were meant to solve. >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "GWT Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to google-web-tool...@googlegroups.com. >> To view this discussion on the web visit >> >> >> https://groups.google.com/d/msgid/google-web-toolkit/c04ab91a-b898-489d-a509-6fafb9a363can%40googlegroups.com >> >> <https://groups.google.com/d/msgid/google-web-toolkit/c04ab91a-b898-489d-a509-6fafb9a363can%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/643460b0-a460-4961-9366-9b0e13cb7990n%40googlegroups.com.
