OK, I guess not many people have used this technique. 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. 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. I hope this explains things better. On Saturday, 17 April 2021 at 20:32:13 UTC+1 t.br...@gmail.com wrote: > > > Le sam. 17 avr. 2021 à 21:15, Jonathon Lamon <jo...@percsolutions.com> 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:* google-web-tool...@googlegroups.com < >> google-web-tool...@googlegroups.com> on behalf of eliasb...@gmail.com < >> eliasb...@gmail.com> >> *Sent:* Saturday, April 17, 2021 2:45:35 PM >> *To:* GWT Contributors <google-web-tool...@googlegroups.com> >> *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 t.br...@gmail.com 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, eliasb...@gmail.com <eliasb...@gmail.com> >> 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 t.br...@gmail.com 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, eliasb...@gmail.com <eliasb...@gmail.com> >> 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 google-web-toolkit-co...@googlegroups.com. >> >> 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 google-web-toolkit-co...@googlegroups.com. >> >> 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 >> google-web-toolkit-co...@googlegroups.com. >> 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 google-web-toolkit-co...@googlegroups.com. >> > 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. 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.
