Converging efforts for Maven Plugin (tbroyer) and GWT Plugin (Eclipse)

[eliasb...@gmail.com]

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.

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.

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.

Please share your thoughts.

[Thomas Broyer]

On Thursday, April 3, 2025 at 6:19:56 PM UTC+2 eliasb...@gmail.com 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), and the GWT Eclipse Plugin 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, 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. 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 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.

[eliasb...@gmail.com]

Good points.

Now you're trying to migrate to the net.ltgt.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 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.

[Thomas Broyer]

On Thursday, April 3, 2025 at 8:19:21 PM UTC+2 eliasb...@gmail.com wrote:

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.

The GWT Eclipse Plugin apparently has some way to launch both GWT CodeServer and a server with Eclipse WTP at the same time (autoconfiguring the CodeServer launchDir and startupUrls): https://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/servers/Tomcat.html 

Or you could maybe use a "Launch Group" launch configuration to run both the server and client in one click ?

[Craig Mitchell]

My experience.  I was initally using the GWT Eclipse Plugin, along with the GAE (Google App Engine) Eclipse Plugin.  Everything worked out of the box, and was simple.

However, GAE then dropped support for the GAE Eclipse plugin, and required me to use Maven (or something similar) and supply my own server.  This wasn't supported by the GWT Eclipse Plugin, so I switched to use the GWT Maven plugin.  It was more complicated, but more flexible.

At no point did I think the GWT Eclipse Plugin would work alongside the GWT Maven Plugin.  They build things differently.

[eliasb...@gmail.com]

The GWT Eclipse Plugin primarily understands Maven modules with "war" packaging, Maven WAR Plugin and GWT in the classpath.

It also somehow understands some of the GWT Maven Plugin directives creating DevMode and codeserver run configurations accordingly.

I have been using this for longer than I can remember and it is still working out of the box without any complications, quick and easy.

Hence my original thought about convergence, so that the plugins can keep working together.

[Craig Mitchell]

Maybe my situation was different.  Google App Engine required an executable war / jar.  Ie:  It must run like this  "java -jar my-app.war".  The GWT Eclipse Plugin couldn't build this, thus I switched to the GWT Maven plugin.

But I admit, the GWT Maven plugin is a little confusing.  Right now, my top level pom has "<packaging>pom</packaging>".  My client module has "<packaging>gwt-app</packaging>".  And my server module has "<packaging>war</packaging>".  Why is the client packaging called "gwt-app", why not just called it "war" like the server. And why does it need to know how the server will be packaged at all, isn't the client just converting Java to JS?  Anyway, it works, and that's the main thing.  🙂

[eliasb...@gmail.com]

I think it all has to do with the new lifecycle introduced by the new Maven plugin.

I am personally not using the new packaging, keeping the runnable module with "war" packaging, all other modules with "jar" packaging and forcing execution of the GWT compilation goal for use as overlay in a downstream module with a "war" packaging.

This satisfies the requirements of my projects which rely on use of overlays in downstream modules with a "war" packaging.

Other projects could be having different requirements for which the Maven plugins new lifecycle could be suitable.

[eliasb...@gmail.com]

"Thomas Broyer", I am afraid only GWT Eclipse Plugin can do what my projects require, anything else involves additional effort, introducing possible complications.

Hence my original thought about convergence of efforts, so that the Maven Plugin and the GWT Eclipse Plugin can keep working together.

[Thomas Broyer]

On Friday, April 4, 2025 at 5:33:04 AM UTC+2 ma...@craig-mitchell.com wrote:

Maybe my situation was different.  Google App Engine required an executable war / jar.  Ie:  It must run like this  "java -jar my-app.war".  The GWT Eclipse Plugin couldn't build this, thus I switched to the GWT Maven plugin.

But I admit, the GWT Maven plugin is a little confusing.

If you're not proficient with Maven (like 95% of its users), mostly poking at it until things work (nobody will blame you, documentation is really lacking), I admit it can certainly be. Maven's design is broken in many ways (Maven 4 goes into the right direction, but it's been years in the making and still not there yet) but it has much more to offer than how most people (try to) use it.

 

Right now, my top level pom has "<packaging>pom</packaging>".  My client module has "<packaging>gwt-app</packaging>".  And my server module has "<packaging>war</packaging>".  Why is the client packaging called "gwt-app", why not just called it "war" like the server.

Because it's not a WAR per se, it's just some ZIP archive that contains the output of the GWT compilation. The only reason the output file is named .war rather than .zip is such that it can easily be used as an "overlay" by a the maven-war-plugin (technically it could be a ZIP, but the maven-war-plugin requires them to be declared in the plugin configuration, which means there's no dependency from the server to the client, so Maven doesn't know that it has to build the client before the server). IIRC, this also was before "webjars" were widely supported (and a few years before Spring Boot); and webjars have other issues: you don't want any of the dependencies from your "client" POM to be resolved when depending on it from the "server" module, which a war gives you "for free": https://maven.apache.org/ref/3.9.9/maven-core/artifact-handlers.html

But as Elias said, the "packaging" in a Maven POM opts in to a build "lifecycle", and this actually is the only reason for that <packaging>gwt-app</packaging>: https://tbroyer.github.io/gwt-maven-plugin/lifecycles.html / https://maven.apache.org/ref/3.9.9/maven-core/default-bindings.html

In other words, this is just how Maven works.

 

And why does it need to know how the server will be packaged at all,

It doesn't (nowhere in the plugin will you see it look at the server module and/or how it's packaged). You're free to use the produced .war archive the way you want. Use the maven-resources-plugin to extract its content if you prefer, it's not a real WAR, it's just a ZIP archive with a .war name, due to Maven's way of resolving things and other limitations.

[Craig Mitchell]

Thanks Thomas.  That makes sense.  Good to get some more knowledge about the plugin (which is fantastic btw.  If it didn't exist, I would be in a lot of trouble, so thank you for creating it!).

And yes, I'm definately in the 95% not proficient with Maven.  😁