Saturday, February 24, 2024

Re: Deploy to Google App Engine (GAE)

In retrospect, I think the GWT BOM (to avoid managing non-GWT dependencies where there's no need to) possibly either should only be used in the client module, or should really only list GWT artifacts. That being said, if you use the Jetty BOM in the server module (and you should), it should override the GWT BOM.

On Saturday, February 24, 2024 at 8:11:38 PM UTC+1 tim_mac...@yahoo.co.uk wrote:
The gwt artifact is indeed in dependency management, but when the jetty-main jar for jetty 11 is a dependency of server module it draws in jetty 9 dependencies and and also gwt-servlet leading to a no javax-servlet error. Remove gwt from the root fixes it.  Maybe this will cause problems beyond this sample.
On Sat, Feb 24, 2024 at 12:14, Thomas Broyer
I could easily write a Main class that runs an embedded Jetty server jagwtvax(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?)
  • 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 ?
On Wed, Feb 21, 2024 at 17:42, Thomas Broyer


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.
It has explicit jetty 11 dependencies.

The WAR project is
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

--
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

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/6a89823a-d496-4a89-bb86-d739b941efdfn%40googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)