Good points. Now you're trying to migrate to the net.ltgt.gwt.maven plugin <https://tbroyer.github.io/gwt-maven-plugin/>, and doing so the Eclipse integration no longer works?
Actually the Eclipse integration seems to be working well so far, just with standard packaging , not the special packaging options offered by the new Maven Plugin. It seems I have probably misused the Maven plugin by trying to assign "gwt-app" packaging to the runnable module. The only way I've ever used GWT+Maven within Eclipse (more than a decade ago) was only through M2E, using Run As… → Maven Build… to run the gwt:codeserver goal I am actually creating Eclipse run configurations of "GWT Development Mode (DevMode)" type, with built-in server port and "Super Development Mode" option which is quite similar to your approach but without separate steps for "codeserver" and application startup. This is required to keep the running steps as uniform and simple as possible for the members of my teams, a single and easy to create Eclipse run configuration for each GWT app. I don't think we can talk about a "convergence" then. It is possible that nothing more is needed, but I would like to hear people's theories. how are you trying to migrate the projects? Refactor them to make them follow the expected structure... It seems initially I only have to replace the old Maven Plugin with the new one, which is actually better than its predecessors because it is not tied to a specific version, making my transformation smoother. In the second stage I intend to switch to GWT 2.12.x from 2.9.0 (or earlier) In the third stage, after Jetty gets decoupled from GWT, I intend to start making efficient use of my "GWT-DevMode-server" project, as discussed in a separate topic. Have you tried with a project generated from the various available archetypes? (either mine, or NaluKit's <https://github.com/NaluKit/gwt-maven-springboot-archetype> using Spring Boot) How does the developer experience in Eclipse look like? I haven't done this for the solutions I am transforming in fear of increasing the transformation effort, but I will happily consider the option for new solutions. On Thursday, 3 April 2025 at 18:53:18 UTC+1 Thomas Broyer wrote: On Thursday, April 3, 2025 at 6:19:56 PM UTC+2 [email protected] wrote: Driven by https://github.com/tbroyer/gwt-maven-plugin/issues/176 I discovered a situation where a Maven structure well understood by GWT Plugin does not seem to be working well in relation to the current Maven plugin (tbroyer) , or vice versa. To make sure I correctly understand the situation: the projects are currently using the MojoHaus plugin (Mojo's Maven Plugin for GWT <https://gwt-maven-plugin.github.io/gwt-maven-plugin/>), and the GWT Eclipse Plugin <https://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/GettingStarted.html> can read its configuration without problem and configure itself so you can use its own *tasks* to run DevMode/CodeServer from within Eclipse, right? Now you're trying to migrate to the net.ltgt.gwt.maven plugin <https://tbroyer.github.io/gwt-maven-plugin/>, and doing so the Eclipse integration no longer works? Not knowing the answer and given that the components are working together, consuming each other's output, I believe Maven plugin and GWT Plugin efforts should be converging, as it seems they had been in the past. I have absolutely no idea what the GWT Eclipse Plugin supports (I had read its docs a while ago but that's it) and whether it has any specific support for my Maven plugin. I personally have made absolutely no effort towards IDE integration besides some very lightweight integration with Eclipse M2E <https://eclipse.dev/m2e/documentation/m2e-making-maven-plugins-compat.html>. The only way I've ever used GWT+Maven within Eclipse (more than a decade ago) was only through M2E, using Run As… → Maven Build… to run the gwt:codeserver goal. At the time, I only used the GWT Eclipse Plugin for its JSNI support in the editor (JS syntax highlighting and formatting within JSNI). There had been discussions to add specific support in the GWT Eclipse Plugin, but I have no idea if that ever actually happened (apparently yes: https://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/maven/Maven.html ) I don't think we can talk about a "convergence" then. It is worth mentioning that the situation I am referring to is only a very small part of a wider effort to transform a large number of enterprise GWT apps that are currently using GWT 2.9.0 and the matching Maven plugin and getting it right the first time matters. Assuming I got the context right, how are you trying to migrate the projects? Refactor them to make them follow the expected structure (see https://github.com/tbroyer/gwt-maven-archetypes and https://github.com/tbroyer/gwt-maven-plugin/issues/127) ? Or only replacing the old goals with the new ones? (only gwt:compile can really be used that way though: https://tbroyer.github.io/gwt-maven-plugin/migrating.html) Or maybe you don't really know where to go and/or what migration path to follow? Have you tried with a project generated from the various available archetypes? (either mine, or NaluKit's <https://github.com/NaluKit/gwt-maven-springboot-archetype> using Spring Boot) How does the developer experience in Eclipse look like? Disclaimer: I've moved away from Eclipse and Maven years ago, and as I said above never used the GWT Eclipse Plugin with Maven projects, nor have I ever used (managed to use; I tried it but it looked so brittle at the time…) Eclipse WTP for server code. I use IDEs mosty as "smart code editors" (refactoring, etc.) that only need to understand sets of source files, and associate them with a compile classpath, and are capable of connecting to a JVM process for debugging. I'm therefore a complete stranger to those IDE-centric developer experiences. -- 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 visit https://groups.google.com/d/msgid/google-web-toolkit/341c609c-253b-43b6-bf40-81e1ec4b182bn%40googlegroups.com.
