On Sat, Apr 17, 2021 at 10:07 PM [email protected] < [email protected]> wrote:
> OK, I guess not many people have used this technique. > This is what we're advocating for years: separate your client and server code, run the server code in one server, run the client code with "DevMode -noserver" or "CodeServer -launcherDir". I started gwt-maven-archetypes with that technique 9 years ago this month, and have been advocating this since then: http://blog.ltgt.net/announcing-gwt-maven-archetypes-project/ This was even before SuperDevMode was a thing (and I was using this project layout at work for nearly 2 years already). And as I linked earlier, GWT Eclipse Plugin supports this for years too ( https://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/servers/Tomcat.html; the Youtube videos date back to Nov 2016) > So, I will try explaining this in a different way. > > Indeed, DevMode runs a CodeServer itself. > > We have a GWT Maven project and we run it using the "DevMode" runner of > "Google Plugin for Eclipse", in a single step, instead of running > CodeServer and servlet container separately etc. > Do you really mean "Google Plugin for Eclipse"? Because it's been dead for quite a while ( https://cloud.google.com/eclipse/docs/migrating-gpe / https://github.com/GoogleCloudPlatform/google-cloud-eclipse/wiki/Migrating-from-the-Google-Plugin-for-Eclipse), replaced by Cloud Tools for Eclipse (from Google) and GWT Eclipse Plugin (single-handedly maintained by Brandon Donnelson, from the original Google Plugin for Eclipse source code, but Brandon no longer does much GWT as Sencha, his employer, silently moved away from it a couple years ago) Google Plugin for Eclipse does not support Eclipse 4.7 (Oxygen), which was released in the summer 2017. > This starts DevMode (with internal codeserver) and a Jetty server on a > given TCP port. > > When accessing the application from a browser, DevMode compiles the GWT > client-code at runtime and delivers it to the browser (no separate > codeserver, no separate servlet container etc.) > > >> Same with CodeServer with -launcherDir, or DevMode with -noserver > This is equivalent to DevMode without "noserver". > > >> What would be the workflow with DevMode serving only static files, and > servlets deployed separately? > The workflow would be the same, it is just the GWT client-side code > wouldn't know how to access the server-side code. > The same as what? Sorry but I want to make sure we clearly understand each other. If you're saying that the workflow would be the same as what you're describing above, then I don't understand: you're deploying servlets separately, so you at least need an additional step to do that. If you're saying it's the same as what you described earlier (and quoted below), then I don't understand why you said “We could run the GWT server-side only code separately, not a problem at all.” Here's what the workflow is/should be for many/most people: - if you're using an IDE with special GWT support (GWT Eclipse Plugin; IntelliJ IDEA Ultimate), then it's just one click; launches both a servlet where your webapp is deployed, and the CodeServer (or DevMode -noserver) for your client code. Similar things are available in some Gradle plugins. I don't know much more as I don't use any of those. - otherwise: 1. launch a server where you webapp is deployed; it should be able to serve static resources from a given directory 2. launch CodeServer (or DevMode -noserver) with -launcherDir (or -war) pointing to the directory where your static resources are served from 3. *there's no third step*; open your webapp (possibly with the help of DevMode's -startupUrl) and upon loading the nocache.js (generated by GWT at launch of step 2, served from the server in step 1) it'll compile your client code on the fly. Everything works *exactly* the same as with DevMode and the embedded webapp server; with the difference that your server-side code is in another server so re-deploying it works differently (depends on that server then, and tooling around it) This is actually (almost) the same as if you used a JS toolchain in "watch" mode. If you'd prefer something more like a "devserver" (à la webpack-dev-server) which would proxy requests to your backend, then I had started https://github.com/tbroyer/gwt-devserver which never gained traction; feel free to fork it, it's under the rather liberal Apache 2.0 license. I hope this explains things better. > > On Saturday, 17 April 2021 at 20:32:13 UTC+1 [email protected] wrote: > >> >> >> Le sam. 17 avr. 2021 à 21:15, Jonathon Lamon <[email protected]> a >> écrit : >> >>> I have just recently set this up.. with the current GWT plugin for >>> Eclipse because I actually needed to run some JaxB servlets. I ran into >>> problems with JaxB servlets not loading when running in embedded Jetty, but >>> setting up CodeServer runner with a launchDir pointing to the war folder >>> and running deploying my GWT project to Tomcat. When the Tomcat server >>> started, it would automatically start the CodeServer. >>> >>> I only saw these problems: >>> >>> Restarting tomcat server without stopping CodeServer would cause >>> multiple CodeServers to run. IE CodeServer does not check if it is already >>> running against an existing launchDir. >>> >>> I ran into classpath and compilation issues where CodeServer would not >>> generate serializable entities for some of my classes that work fine under >>> DevMode. >>> >>> CoseServer seemed to take an extra long time to compile vs DevMode. >>> >> >> Given that DevMode actually just runs CodeServer itself (literally: >> https://github.com/gwtproject/gwt/blob/8e09375adcc0a3ac976ba74286589d6d7007958d/dev/core/src/com/google/gwt/dev/shell/SuperDevListener.java#L99), >> I don't think this is possible. >> Could be due to more pressure on your computer resources (memory and/or >> CPU) in that configuration maybe? >> >> >>> >>> My project is extremely large so there are many modules, some gwt some >>> not, somewhere between 20-30 projects altogether and Multiple GWT modules. >>> Runs fabulously, for the most part under DevMode, but CodeServer just seems >>> to have trouble. I am surr that this is just do to various options set >>> differently at runtime and perhaps some classpath loading differences, but >>> an example that shows how to run CodeServer to reproduce the effect of >>> running under DevMode would be imperative before removing DevMode. >>> >> >> IIRC the CodeServer arguments are logged in DevMode window so you could >> copy-paste them. Use the same classpath, just change the main class from >> DevMode to CodeServer and change the arguments. >> Or continue to use DevMode and just pass -noserver. >> >> >>> >>> >>> >>> >>> Jonathon Lamon >>> >>> DevOps Manager / Principal Engineer Special Projects >>> Perceptronics Solutions Inc. >>> Cell 269-205-4649 <(269)%20205-4649> >>> www.percsolutions.com >>> >>> ------------------------------ >>> *From:* [email protected] < >>> [email protected]> on behalf of [email protected] < >>> [email protected]> >>> *Sent:* Saturday, April 17, 2021 2:45:35 PM >>> *To:* GWT Contributors <[email protected]> >>> *Subject:* Re: [gwt-contrib] Asking for decision on DevMode embedded >>> Jetty support >>> >>> >>> CAUTION -- EXTERNAL E-MAIL >>> During development, >>> with "SuperDevMode"+"Jetty" and "Google Plugin for Eclipse", >>> GWT client-side code compilation (including the nocache.js files) is >>> done at runtime by DevMode. >>> >>> Any other scenario demands that we, >>> separately compile the GWT client-side code, >>> separately run a servlet, >>> separately deploy the GWT code to the server (both client-side and >>> server-side), >>> separately run GWT CodeServer, >>> then run a browser, >>> then genearate the CodeServer link etc. >>> >>> The complexity difference is obvious. >>> >>> I hope this explains my case. >>> >>> On Saturday, 17 April 2021 at 19:36:18 UTC+1 [email protected] wrote: >>> >>> If it's not a problem for you to serve servlets separately, could you >>> explain why you couldn't have this other server also serve the host page >>> and nocache.js file? Is that due to, maybe, how your projects are >>> structured? (Could you give more details then?) >>> Trying to understand what's blocking people here. >>> >>> Le sam. 17 avr. 2021 à 20:06, [email protected] <[email protected]> >>> a écrit : >>> >>> This feels much better now. >>> >>> Serving only static GWT client-side via DevMode+Jetty sounds good. >>> >>> We could run the GWT server-side only code separately, not a problem at >>> all. >>> >>> But, how would the GWT client-side know how to access GWT server-side? >>> >>> On Saturday, 17 April 2021 at 18:45:39 UTC+1 [email protected] wrote: >>> >>> Moreover, we have to be careful when we say "remove Jetty", because >>> Jetty is used in CodeServer and JUnitShell. >>> Really the question here is about removing the ability to serve webapps, >>> with servlets, from DevMode. >>> >>> Le sam. 17 avr. 2021 à 19:34, [email protected] <[email protected]> >>> a écrit : >>> >>> This is a very good idea. >>> >>> I am afraid though that it wouldn't change the situation much because >>> the classpaths of GWT and Jetty co-exist and must be aligned regardless. >>> >>> But, I would stand corrected. >>> >>> On Saturday, 17 April 2021 at 17:25:19 UTC+1 Paul Robinson wrote: >>> >>> Would it be plausible to split GWT into two projects - one as it is now >>> but without Jetty built in, and another that adds the bits relating to >>> Jetty? >>> >>> Then the GWT Jetty project could be maintained by those that require it. >>> >>> Paul >>> >>> -- >>> >>> 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 on the web visit >>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/9cce0909-56fc-4804-a032-103184c05af1n%40googlegroups.com >>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/9cce0909-56fc-4804-a032-103184c05af1n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> 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 on the web visit >>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/94c5c53d-b72a-4887-a617-4d1064c7c8fan%40googlegroups.com >>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/94c5c53d-b72a-4887-a617-4d1064c7c8fan%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "GWT Contributors" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/google-web-toolkit-contributors/iU9hckIab2o/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/4486df4d-553d-409f-b3a8-4b4887ff0b9fn%40googlegroups.com >>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/4486df4d-553d-409f-b3a8-4b4887ff0b9fn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> CAUTION -- EXTERNAL E-MAIL - Do not click links or open attachments >>> unless you recognize the sender. >>> >>> ------------------------------ >>> The content of this email is confidential and intended for the recipient >>> specified in message only. It is strictly forbidden to share any part of >>> this message with any third party, without a written consent of the sender. >>> If you received this message by mistake, please reply to this message and >>> follow with its deletion, so that we can ensure such a mistake does not >>> occur in the future. >>> >>> -- >>> 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 on the web visit >>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/BN3P110MB0354A199D56BBA0158B8D7E2DC4B9%40BN3P110MB0354.NAMP110.PROD.OUTLOOK.COM >>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/BN3P110MB0354A199D56BBA0158B8D7E2DC4B9%40BN3P110MB0354.NAMP110.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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 on the web visit > https://groups.google.com/d/msgid/google-web-toolkit-contributors/4ab443c9-cfea-4d63-8cfe-90311cab0c64n%40googlegroups.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/4ab443c9-cfea-4d63-8cfe-90311cab0c64n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> -- 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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAEayHEPWYGJi_Eh0H%2BkAYGJZ%3Dj%2BfgTqpOu8HbAr6Y3_ADOwn%3DQ%40mail.gmail.com.
