Thanks to all who helped and inspired me, I've gotten rid of the Eclipse GWT plugin and have configured a Gradle project that uses Eclipse plugin, so it can be used standalone from command line or imported to Eclipse.
When imported to Eclipse it represents a webapp that can be added to a server of my choice configured in the Eclipse Servers tab. Also it includes the GWT CodeServer task that runs GWT Dev mode as separate process with separate classpath, avoiding Jar hell of the Eclipse GWT plugin, where dependencies of GWT-dev, GWT-user, Jetty and my app are mixed in the same JVM classpath. I hope finally to find a time to strip the project down to essentials and publish it to the Github. On Monday, February 21, 2022 at 9:07:19 PM UTC+1 tekkyru wrote: > Sounds interesting, I'll definitely give it a try, thank you - and for the > gradle file, I really need a production grade gradle example > > понедельник, 21 февраля 2022 г. в 11:27:04 UTC+1, Luis Fernando Planella > Gonzalez: > >> > Our current workflow is using SuperDevMode + Jetty and I'd like to >> provide similar experience to our team. >> I had a similar concern, as before we both SuperDevMode and the app in >> the same Java process. >> After the switch, we need to start the codeserver and then the app, via >> Tomcat. But, things went well, because: >> >> 1. You don't have to start your app in the build tool and connect >> remotely. The codeserver will write its files to the same place as the >> regular compilation would, and you can start your app in a debug session >> in >> Eclipse. We're using the built-in Tomcat server (with Eclipse WTP). Just >> make sure that after starting the codeserver, you have your workspace >> refreshed, so Eclipse can publish it accordingly (that's why we wrote the >> script, as mentioned in the previous post) >> 2. Starting the codeserver is actually slower than the app (at least >> for us, and the app is huge). When you debug the app, you'll eventually >> do >> an incompatible change that needs to restart the app. When using the >> codeserver as a separated process, it stays there, in the same place, >> even >> when you restart the app. IMO, this ended up being more productive than >> the >> previous setup >> 3. If GWT 3 is ever released, having a separated codeserver will be >> the only option >> >> >> Em domingo, 20 de fevereiro de 2022 às 20:55:55 UTC-3, >> [email protected] escreveu: >> >>> Thanks for the answer >>> >>> > Can't you somehow disable the module path or put all dependencies in >>> the classpath rather than the module path? >>> >>> Do you mean disabling java.xml module of JRE and depend on all xml stuff >>> explicitly? It means I'd have to rely on dependencies instead of stock >>> libraries (general app architecture choice) just to comply with a flawed >>> development tool needed only to run debug sessions. I'd prefer to avoid it >>> unless it's the only way. >>> >>> > Alternatively, how about not using the Eclipse GWT Plugin? >>> >>> Our current workflow is using SuperDevMode + Jetty and I'd like to >>> provide similar experience to our team. >>> I saw such solutions (using gradle gretty plugin), so far decided >>> against it. As far as I understand running the code server and my webapp >>> via Gradle without Eclipse GWT plugin brings more hassle into everyday >>> development routine. This way the webapp must be launched not as Eclipse >>> debugging session but as Gradle task, and connected via remote debugging >>> session. I'd like to avoid it. >>> >>> воскресенье, 20 февраля 2022 г. в 12:33:18 UTC+1, [email protected]: >>> >>>> On Saturday, February 19, 2022 at 1:57:16 AM UTC+1 [email protected] >>>> wrote: >>>> >>>>> Hi Jasper >>>>> >>>>> I'll be just glad if my current progress saves someone's time. >>>>> I progress on step by step basis, so far I succeeded in Eclipse build >>>>> and debugging. >>>>> >>>>> Most of my problems were caused by combination of JDK11+ (namely >>>>> modules) + Gradle + Eclipse + Eclipse GWT Plugin. >>>>> >>>>> Reason: GWT SDK gwt-dev.jar contains lot of classes that must not be >>>>> visible to Eclipse compiler, but in fact they are, causing dreaded "The >>>>> package org.w3c.dom is accessible from more than one module: <unnamed>, >>>>> java.xml" error. >>>>> When `gradle build` is issued in command line the gwt-dev.jar from the >>>>> maven repository is linked, it contains exactly essential google classes >>>>> and nothing more. Thus the build succeeds. >>>>> >>>>> But when you import such project in Eclipse under JDK11+ (I use JDK17) >>>>> and select a GWT SDK there're lots of build errors caused by "The package >>>>> is accessible from more than one module" >>>>> >>>> >>>> Can't you somehow disable the module path or put all dependencies in >>>> the classpath rather than the module path? >>>> >>>> https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fref-properties-build-path.htm&resultof%3D%2522%256a%2570%256d%2573%2522%2520%2522%256a%2570%256d%2522%2520 >>>> >>>> >>>> Alternatively, how about not using the Eclipse GWT Plugin? >>>> >>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/ae2bf610-a12a-4b9f-be88-67cf67010fd7n%40googlegroups.com.
