In my experience, as long as the GWT server-side is lightweight enough to run under Jetty there shouldn't be any major problems with any structure.
Also, with Maven (or other build engines) you can manipulate the classpath and resolve SuperDevMode+Jetty classpath conflicts during development. In general, GWT applications are expected to be quite lightweight, not monolithic, comparable to demo-sized apps in terms of capability to run under SuperDevMode's embedded Jetty. Any heavyweight logic should be moved to separate applications, a "microservices" approach. Therefore, I see no reason to stop using SuperDevMode with Embedded Jetty. Your structure is in fact even more simplified and lightweight, even though it requires additional APIs work. I would be happy to give it a try in one of our future projects. I haven't used https://github.com/interseroh/demo-gwt-springboot but I have created my own equivalent at https://github.com/eliasbalasis/eclipse-gwt-recipe I hope this helps Elias On Tuesday, 4 May 2021 at 16:29:45 UTC+1 lofid...@gmail.com wrote: > @Thomas: thanks a lot for the insight... > > Yes, you are correct I only use the embedded Jetty Server to serve > (development-only) static HTML page. And I won't ever need more than > this... > > So then I think, I don't really understand what @Elias means sofar... I > thought, he had the same installment like my structure? Damn already work > with GWT since 2008 but still cannot see what the difference using devmode > in my case and in @Elias case... :-) :-) > > I had once this structure: https://github.com/interseroh/demo-gwt-springboot > but today I won't do this anymore... The classpath is a very big problem > here... > > @Elias: Is there any problem to move to the structure like I have here in > this example? https://github.com/gwtboot/domino-rest-enum-date > > I once write this tool MoveToMaven: > https://github.com/crowdcode-de/MoveToMaven to move Ant projects to Maven > projects. Actually it is not that complex to write such a tool to move your > "old" GWT Maven structure to the new GWT Maven structure automatically. > It's good to have such a transformer if you have a lot of Maven projects... > > Thanks, > Lofi > > eliasb...@gmail.com schrieb am Dienstag, 4. Mai 2021 um 10:20:53 UTC+2: > >> My 2 cents, >> >> I understand very well where "Lofi" is coming from. >> >> He tries to simplify the GWT server-side by moving all the potentially >> conflicting classpath dependencies to a separate application. >> >> This recipe indeed involves an extra step but it doesn't change at all >> the situation with "DevMode+Jetty" and the associated classpath >> misalignment, particularly with GWT 2.9+ while the >> "DevMode+Jetty+CodeServer" combination still runs in a single step. >> Therefore, I still vote in favor of keeping DevMode, removing support for >> Java7, upgrading Jety to more recent version and use of same transitive >> dependencies between GWT and Jetty (e.g. ASM). >> >> FYI, if it helps anyone, I have found a workaround to the classpath >> misalignment issue (see >> https://github.com/gwtproject/gwt/issues/9693#issuecomment-822016533) >> which works both for GWT2.9+ and previous versions. >> >> On Tuesday, 4 May 2021 at 08:53:21 UTC+1 t.br...@gmail.com wrote: >> >>> On Tue, May 4, 2021 at 3:15 AM 'Lofi Dewanto' via GWT Contributors < >>> google-web-tool...@googlegroups.com> wrote: >>> >>>> What I don't understand so far, why does Jetty disturbs the whole >>>> classpath concept? >>> >>> >>> There are many issues, depending on who you ask and how they use GWT. >>> The issue that started this discussion about upgrading Jetty is that >>> Jetty scans the WEB-INF/lib JARs, and the version we use in GWT will fail >>> on any module-info.class. >>> Other issues with how Jetty is used in DevMode is that we give it a >>> special WebAppClassLoader that doesn't work like a standard web-app >>> classloader in that it will resolves classes from both the WEB-INF/classes >>> and WEB-INF/lib, and the DevMode classpath. This was done so that you don't >>> need to "assemble" an "exploded WAR" (compiling your server code to >>> WEB-INF/classes, putting your server dependencies to WEB-INF/lib). This has >>> caused *many* issues over the years (Spring failing because it saw its >>> configuration twice: from the WEB-INF/classes and from the classpath; some >>> libraries from the classpath leaking to the web-app classloader; etc.), and >>> makes upgrading Jetty is unnecessarily hard and error-prone (last time we >>> did, I spent hours fixing it). >>> And I'm not even talking about people asking for JSP support, or >>> jetty-web.xml support (e.g. to configure form authentication or JNDI >>> resources), or web-fragments, annotation scanning (that's now causing the >>> issues with modules) >>> >>> Everything would be much much simpler if we removed all those features >>> to only support the bare minimum (static files), or possibly re-introduce >>> the <servlet> support in gwt.xml (and totally removing web.xml support), or >>> as a last resort making it extra-clear that this only supports "demo-size" >>> projects (after we remove the custom classloader, and possibly JSP and >>> jetty-web.xml) and that if it breaks or you need more features then you >>> just don't use it. >>> >>> The last issue is actually a non-issue (and that was actually Elias' >>> problem, or at least part of it): people misconfiguring their classpath and >>> including other Jetty or servlet libraries in the classpath. We can't do >>> anything here, that's a classpath management issue and it would be the same >>> with many other dependencies (e.g. upgrade HTMLUnit, you'll see your tests >>> fail). >>> >>> >>>> *I only use devmode on the client *and on the client I don't have >>>> server libs... Is it not possible just to use the needed Jetty server for >>>> GWT (I'm not sure where else do we need the Jetty libs in GWT code)? >>> >>> >>> Jetty is used for the CodeServer itself (that could probably be migrated >>> to using com.sun.net.httpserver), and for the JUnitShell (that one needs to >>> support basic servlets, so no com.sun.net.httpserver here). >>> And the Jetty version needs to be aligned with what HTMLUnit uses, as it >>> requires some Jetty client libraries (mostly for websocket support IIRC) >>> that transitively require some Jetty "common" libraries (jetty-util, >>> jetty-io). >>> >>> >>>> Because actually I don't care what version of Jetty should be used in >>>> GWT... the main thing: *I could run web server + code server in the >>>> same process *with one execution. >>> >>> >>> I don't really get what point you're trying to make. If you don't have >>> server code in your DevMode, then you're not impacted by the change being >>> discussed here. >>> >>> Another possibility: run the Jetty for devmode in the GWT Maven plugin? >>>> So you only have the Jetty on the classpath of the Maven plugin? >>>> >>>> To show you my use case, here is an example: >>>> https://github.com/gwtboot/domino-rest-enum-date >>>> >>> >>> Where you're starting your Spring Boot server separately from DevMode >>> (so you have 2 processes, not just one, contrary to what you're saying >>> above), whose embedded server only serves a (development-only) static HTML >>> page. >>> That's probably not how I would work with Spring Boot, but indeed that >>> works too. >>> >>> -- >>> 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 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/ca5d2495-0958-45b5-9ce1-a8a429ae6f89n%40googlegroups.com.
