> 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:
- 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)
- 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
- 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, tequil...@gmail.com 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, t.br...@gmail.com:On Saturday, February 19, 2022 at 1:57:16 AM UTC+1 tequil...@gmail.com wrote:Hi JasperI'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?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 google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/b90a7c37-81ad-4768-ad97-e6a830e9a670n%40googlegroups.com.
No comments:
Post a Comment