Saturday, April 5, 2025

Possible to access list of included methods from Linker?

Hi all,

I'm implementing a custom linker as a subclass of AbstractLinker. Is it possible to determine from the set of Artifacts, or other information, if specific Java methods were included in the final emitted build?

Thanks!

Alex

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/05751bbe-46e7-4cad-af39-6fbb2dfba926n%40googlegroups.com.
Posted by at No comments:

Friday, April 4, 2025

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

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.  😁

On Saturday, 5 April 2025 at 3:22:15 am UTC+11 Thomas Broyer wrote:
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.

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/ad4bf9a3-49ce-49c4-a233-0153a8cf8917n%40googlegroups.com.
Posted by at No comments:

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



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.

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/888c3099-5843-4c68-b73d-4f2c94ed8d8cn%40googlegroups.com.
Posted by at No comments:

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

"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.

On Thursday, 3 April 2025 at 22:00:11 UTC+1 Thomas Broyer wrote:
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 ?

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/af98b438-28d5-4ad4-84f8-fc1a5ee77068n%40googlegroups.com.
Posted by at No comments:

Thursday, April 3, 2025

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

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.

On Friday, 4 April 2025 at 04:33:04 UTC+1 Craig Mitchell 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.  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.  🙂

On Friday, 4 April 2025 at 1:40:08 pm UTC+11 eliasb...@gmail.com wrote:
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.


On Friday, 4 April 2025 at 03:06:12 UTC+1 Craig Mitchell wrote:
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.

On Friday, 4 April 2025 at 8:00:11 am UTC+11 Thomas Broyer wrote:
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 ?

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/226eed49-3712-4d32-8668-14ca6ec71481n%40googlegroups.com.
Posted by at No comments:

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

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.  🙂

On Friday, 4 April 2025 at 1:40:08 pm UTC+11 eliasb...@gmail.com wrote:
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.


On Friday, 4 April 2025 at 03:06:12 UTC+1 Craig Mitchell wrote:
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.

On Friday, 4 April 2025 at 8:00:11 am UTC+11 Thomas Broyer wrote:
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 ?

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/855bb416-ed67-41ef-b9e3-78804df72f7dn%40googlegroups.com.
Posted by at No comments:

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

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.

On Friday, 4 April 2025 at 03:06:12 UTC+1 Craig Mitchell wrote:
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.

On Friday, 4 April 2025 at 8:00:11 am UTC+11 Thomas Broyer wrote:
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 ?

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/03a694be-adc4-41ee-ba28-43f331b67432n%40googlegroups.com.
Posted by at No comments:

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

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.

On Friday, 4 April 2025 at 8:00:11 am UTC+11 Thomas Broyer wrote:
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 ?

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/af8e6780-c656-4988-9130-7c13e0081505n%40googlegroups.com.
Posted by at No comments:

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



On Thursday, April 3, 2025 at 8:19:21 PM UTC+2 eliasbalasis@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 ?

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/950d8cfd-20f9-4ae8-a046-00e12fb5f6b4n%40googlegroups.com.
Posted by at No comments:

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

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.

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 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.

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/341c609c-253b-43b6-bf40-81e1ec4b182bn%40googlegroups.com.
Posted by at No comments:

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



On Thursday, April 3, 2025 at 6:19:56 PM UTC+2 eliasbalasis@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.

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/cfbdab62-6bca-4308-ba35-1fe0eade4b6en%40googlegroups.com.
Posted by at No comments:

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

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.

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/e3c5e73a-d6cd-47dd-9b5c-3e7c1aa2a244n%40googlegroups.com.
Posted by at No comments:

Tuesday, April 1, 2025

Re: Compatibility of GWT 2.10.0 with GXT 2.3.1.a

I guess it's tricky - GXT is still owned by Sencha, even though I don't believe they actively sell it these days. My firm was one of the early customers, and we still pay Sencha for maintenance. TBH, there's nothing much in the way of enhancements going on and we always have to prod them when we find issues with newer versions of GWT (sometimes even sending them the mods we find our side). But they have come through with fixes and changes we needed. This thread here describes one of those cases - we're now on GWT 2.12.0 and GXT 4.2.0 and it's all working fine together, but we did have to push Sencha to get mods done for this specific case and issue a new GXT release for that.

FWIW - a few of our panels still use the older GWT-Ext widget set which later became part of SmartGWT. We've had no issues with those in GWT upgrades, although of course no one maintains them so it is very much "fix it yourself". It's also non -trivial making GXT and GWT-Ext live side by side in one app due to overlaps in the CSS style names. We had to create a manual munging script to sort that out, but the effort of that was lower than recoding all of those panels - we replace them slowly over time as we need.

-Rob

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/b91e5590-2b3a-4dff-b3ef-340db3fa519fn%40googlegroups.com.
Posted by at No comments:

Monday, March 31, 2025

Re: Suggestion on upgrading gwt-2.6.1 to latest

It is so helpful it was some local issues and i resolved many thanks @colin 

Best Regards,
Wejden MRABTI

Ingénieur étude et développement


Le lun. 31 mars 2025 à 16:30, Colin Alworth <colin@colinalworth.com> a écrit :
From publicly available sources, I can only confirm three compile errors in GXT 2.3.1a-gwt22 (the final release of GXT 2, compatible at the time with the latest GWT version) when compiling with GWT 2.12.2. I also verified with GWT 2.10.1, gxt itself has no other compile errors. Those errors are in TreePanel, ListView, and ListField, and all three can be fixed with a cast (as above, it appears that redistributing the modifications is against the license terms, but I feel confident in saying just that a cast fixes each). It is possible that building with your entire application changes things in some way, but I am compiling with -failOnErrors which _should_ outright fail if any class isn't entirely valid for use in GWT.

GXT 2 has no external third-party dependencies.

I cannot confirm that GXT's Component is no longer compatible with GWT 2.10+'s Widget type.

It seems likely that remaining issues are part of your application, rather than GXT 2 (or GWT)?

On Monday, March 31, 2025 at 7:13:48 AM UTC-5 wejden...@gmail.com wrote:
thanks @colin @leon

Aside from the licensing concerns, I'm mostly interested in the technical and conceptual side of things.

From a conceptual standpoint — for those who have attempted similar upgrades —
Have you encountered the same main issues I've listed below when trying to run GXT 2.3.1a with GWT 2.10?

Main issues I'm seeing:

  • Component (GXT) is no longer compatible with Widget (GWT), breaking most UI layout logic

  • Many core GXT components like TextField, LabelField, FormPanel, etc. are no longer usable

  • GWT 2.10 + Java 11 enforces stricter type checks → tons of generic mismatches and interface conflicts

  • Several third-party dependencies are broken or require updates 

I'd love to know if others faced similar roadblocks or found any strategies to make GXT 2.x work (even partially) with GWT 2.10 — or if full migration to GWT-native components was the only way forward ;)

Thanks again for any insight!


wejden



Le lun. 31 mars 2025 à 13:59, Colin Alworth <co...@colinalworth.com> a écrit :
Their license is pretty clear on this matter:

> We provide You with source code to the Sencha SDKs so that You can create Modifications and Applications. While You retain all rights to any original work authored by You as part of the Modifications, We continue to own all copyright and other intellectual property rights in the Sencha SDKs.

It does however go on to say that you cannot share the modified sdk though (nor the patches themselves):

> You may not redistribute the Sencha SDKs or Modifications other than by including the Sencha SDKs or a portion thereof within Your Application.


I am not a lawyer, I am not your lawyer, etc. 


On Mon, Mar 31, 2025, at 6:43 AM, Leon wrote:
Hi Wejden, I would still recommend to check on whether or not that includes the right to modify and/or recompile the sources.

On Mon, Mar 31, 2025 at 1:40 PM Wejden Mrabti <wejden...@gmail.com> wrote:
@leon we already have commercial licence 


Best Regards,
Wejden MRABTI

Ingénieur étude et développement


Le lun. 31 mars 2025 à 12:46, Leon <leon.p...@gmail.com> a écrit :
Hi Wejden,

GXT does not have an open source licensing as far as I know. Not sure if you're legally allowed to modify & recompile the sources.
That might be worth checking out before you put a lot of work into it.

rg,

Leon.


On Mon, Mar 31, 2025 at 12:20 PM Wejden Mrabti <wejden...@gmail.com> wrote:

many thanks @Colin and @Jens

I'm currently testing a partial migration of my GWT application to Java 11 and GWT 2.10. To get a better idea of the work involved, I tried compiling just one module of the project.

Here's what I've done so far:

 Main issues I'm facing:

  • Component (GXT) is no longer compatible with Widget (GWT) ===> breaks all UI layouts

  • Many GXT-based custom components like com.extjs.gxt.ui.client.widget.form.TextField, LabelField, etc. are not compatible anymore

  • Stricter typing in Java 11 + GWT 2.10 ===> leads to many generic/interface mismatches

  • Several dependencies also need to be replaced or upgraded

My question:

Given that the application is heavily dependent on GXT 2.3.1a, especially for the client-side (grids, forms, fields, etc.), Is it worth trying to patch and adapt GXT further?
Or should I progressively migrate everything to native GWT widgets (like Composite, DataGrid,  etc.)?

Has anyone gone through a similar migration? Are all these issues common when trying to use a patched GXT with GWT 2.10?

Any advice or shared experience would be super appreciated!

Thanks a lot 

wejden

Le dimanche 23 mars 2025 à 20:26:32 UTC+1, Colin Alworth a écrit :
#1 I think Jens covers it well - something is almost certainly wrong with your modified jar or how the classpath is built.

For #2, the "-server" argument lets you specify a com.google.gwt.core.ext.ServletContainerLauncher type, so org.eclipse.jetty.server.Server will not suffice. If you do not specify one, as of GWT 2.12 the old default of com.google.gwt.dev.shell.jetty.JettyLauncher (using a wrapped Jetty 9) is still used, which is what it sounds like you want anyway. This will change in the future, see https://github.com/gwtproject/gwt/issues/10057 and linked issues, If you're interested in something newer than the default Jetty 9, also see https://groups.google.com/g/google-web-toolkit/c/3dSoHpHD5jY/m/faAeQeJ-AwAJ and https://groups.google.com/g/google-web-toolkit-contributors/c/7jvGVaiSUdI.

Note that Jetty 9 sometimes doesn't behave nicely when it tries to scan your classpath - if it finds something that it can't understand while looking for annotations, it will break. This will result in an error something like
java.lang.IllegalArgumentException: Unsupported class file major version 64
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:199)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:180)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:166)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:287)
at org.eclipse.jetty.annotations.AnnotationParser.scanClass(AnnotationParser.java:932)
at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:734)
... 6 more


#3, nothing special should be required - besides the wrong instance passed to -server, what errors are you seeing?

Re your note: you should not need to deploy a complete war to tomcat for local development - the best way to think about this is "If I wasn't using GWT, how would I want to debug my server", then amend that slightly to permit SDM to change files in the same sort of way that you would either manually edit JS/HTML or you'd use a tool like npm/etc.

On Sunday, March 23, 2025 at 3:23:07 AM UTC-5 wejden...@gmail.com wrote:

Hello!  

I am following your conversation because i am working on same issues :    

Migrating GWT/GXT project to GWT 2.10 + Java 11 + Jetty 9

Initial Context on Legacy project using:

  • GWT 2.8.2

  • GXT 2.3.1a-gwt22

  • Embedded Jetty

  • Java 8

Migration Goal

Update the project to use:

  • Java 11

  • GWT 2.10.1

  • Jetty 9

  • A custom-built GXT version compatible with GWT 2.10

Steps Already Completed 

1. GXT Recompilation and Installation

  • Cloned the GXT 2.3.1a sources.

  • Adapted the code to compile with GWT 2.10.1.

  • Successfully built gxt-main-2.3.1a-gwt2.10.jar.

  • Installed it locally using:


2. Maven Configuration Updated

  • Switched to Java 11 using maven.compiler.source and target.

  • GWT updated to version 2.10.1.

  • Added the locally installed GXT dependency

3. GWT Module Inheritance Added
4. GXT Verification

  • Confirmed GXT.gwt.xml is present inside the JAR (jar tf checked).

  • JAR added to the Eclipse launch configuration (Run Configurations > Classpath).

Jetty Configuration Jetty 9 Already in Use

  • Version confirmed: 9.4.52.v20230823 (via mvn dependency:tree).

  • Dependencies have <scope>compile</scope> (not provided).

  • jetty-server-9.4.52.v20230823.jar appears in the Eclipse classpath.


Current Blocking Issues

1. GXT Not Found at Runtime

When launching GWT DevMode: Unable to find 'com/extjs/gxt/ui/GXT.gwt.xml' on your classpath

Despite:

  • The file being present in the JAR.

  • The JAR being listed in the Run Configurations > Classpath.

  • Proper inheritance in the .gwt.xml file.

2. Jetty Server Class Not Found

Tried using the argument:

-server org.eclipse.jetty.server.Server

ClassNotFoundException: org.eclipse.jetty.server.Server

Even though the JAR is present in the classpath, and Jetty 9 is confirmed to be in use.

So i need to understand

  1. Why is GWT DevMode (or CodeServer) unable to find com.extjs.gxt.ui.GXT.gwt.xml, even though it is present and properly declared?

  2. How can I resolve the ClassNotFoundException for org.eclipse.jetty.server.Server, despite Jetty 9 being correctly added?

  3. Are there any special configurations or recommendations for running GWT 2.10 with Jetty 9 and Java 11 in Eclipse?

Important note: I do not want to switch to a Tomcat 9 deployment (war packaging) as a workaround. The current state of the project makes the packaging and deployment process extremely slow — over one hour just to build and deploy. Therefore, I need a solution that works using GWT Super DevMode and embedded Jetty

Thanks in advance for any help or suggestions.


__wejden



Le mercredi 12 mars 2025 à 17:32:47 UTC+1, Jens a écrit :
As Colin said you can use @WebServlet and enable configuration via annotation scanning in your servlet container. However if your application is large then scanning might slow your deployment down. If deployment time is not a concern then it is the easiest solution. There are additional annotations for other classes you normally add to your web.xml.

If you don't like class scanning during deployment time you can write an annotation processor that picks up all these @WebServlet annotated servlets and generates a class that registers them using the ServletContext API. Then you use that generated class in a custom ServletContextListener implementation to register everything. That ServletContextListener would then be the only entry in your web.xml. Alternatively, if you use Jetty as servlet container you can use Jetty's quickstart module to let it generate a web.xml by scanning your code once (as part of the build process).

-- J.



--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.


--
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-tool...@googlegroups.com.


--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.


--
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-tool...@googlegroups.com.

--
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-tool...@googlegroups.com.


--
Best Regards,
Wejden MRABTI

Ingénieur étude et développement

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/56edc394-c92f-4cf8-aab4-08b7caf3137dn%40googlegroups.com.

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/CADMk%2BV%2B9FOMm0%3DPdCb6DCJApZv5Sbj1tjUL07sw_Ga203hFFpA%40mail.gmail.com.
Posted by at No comments:

Re: Suggestion on upgrading gwt-2.6.1 to latest

From publicly available sources, I can only confirm three compile errors in GXT 2.3.1a-gwt22 (the final release of GXT 2, compatible at the time with the latest GWT version) when compiling with GWT 2.12.2. I also verified with GWT 2.10.1, gxt itself has no other compile errors. Those errors are in TreePanel, ListView, and ListField, and all three can be fixed with a cast (as above, it appears that redistributing the modifications is against the license terms, but I feel confident in saying just that a cast fixes each). It is possible that building with your entire application changes things in some way, but I am compiling with -failOnErrors which _should_ outright fail if any class isn't entirely valid for use in GWT.

GXT 2 has no external third-party dependencies.

I cannot confirm that GXT's Component is no longer compatible with GWT 2.10+'s Widget type.

It seems likely that remaining issues are part of your application, rather than GXT 2 (or GWT)?

On Monday, March 31, 2025 at 7:13:48 AM UTC-5 wejden...@gmail.com wrote:
thanks @colin @leon

Aside from the licensing concerns, I'm mostly interested in the technical and conceptual side of things.

From a conceptual standpoint — for those who have attempted similar upgrades —
Have you encountered the same main issues I've listed below when trying to run GXT 2.3.1a with GWT 2.10?

Main issues I'm seeing:

  • Component (GXT) is no longer compatible with Widget (GWT), breaking most UI layout logic

  • Many core GXT components like TextField, LabelField, FormPanel, etc. are no longer usable

  • GWT 2.10 + Java 11 enforces stricter type checks → tons of generic mismatches and interface conflicts

  • Several third-party dependencies are broken or require updates 

I'd love to know if others faced similar roadblocks or found any strategies to make GXT 2.x work (even partially) with GWT 2.10 — or if full migration to GWT-native components was the only way forward ;)

Thanks again for any insight!


wejden



Le lun. 31 mars 2025 à 13:59, Colin Alworth <co...@colinalworth.com> a écrit :
Their license is pretty clear on this matter:

> We provide You with source code to the Sencha SDKs so that You can create Modifications and Applications. While You retain all rights to any original work authored by You as part of the Modifications, We continue to own all copyright and other intellectual property rights in the Sencha SDKs.

It does however go on to say that you cannot share the modified sdk though (nor the patches themselves):

> You may not redistribute the Sencha SDKs or Modifications other than by including the Sencha SDKs or a portion thereof within Your Application.


I am not a lawyer, I am not your lawyer, etc. 


On Mon, Mar 31, 2025, at 6:43 AM, Leon wrote:
Hi Wejden, I would still recommend to check on whether or not that includes the right to modify and/or recompile the sources.

On Mon, Mar 31, 2025 at 1:40 PM Wejden Mrabti <wejden...@gmail.com> wrote:
@leon we already have commercial licence 


Best Regards,
Wejden MRABTI

Ingénieur étude et développement


Le lun. 31 mars 2025 à 12:46, Leon <leon.p...@gmail.com> a écrit :
Hi Wejden,

GXT does not have an open source licensing as far as I know. Not sure if you're legally allowed to modify & recompile the sources.
That might be worth checking out before you put a lot of work into it.

rg,

Leon.


On Mon, Mar 31, 2025 at 12:20 PM Wejden Mrabti <wejden...@gmail.com> wrote:

many thanks @Colin and @Jens

I'm currently testing a partial migration of my GWT application to Java 11 and GWT 2.10. To get a better idea of the work involved, I tried compiling just one module of the project.

Here's what I've done so far:

 Main issues I'm facing:

  • Component (GXT) is no longer compatible with Widget (GWT) ===> breaks all UI layouts

  • Many GXT-based custom components like com.extjs.gxt.ui.client.widget.form.TextField, LabelField, etc. are not compatible anymore

  • Stricter typing in Java 11 + GWT 2.10 ===> leads to many generic/interface mismatches

  • Several dependencies also need to be replaced or upgraded

My question:

Given that the application is heavily dependent on GXT 2.3.1a, especially for the client-side (grids, forms, fields, etc.), Is it worth trying to patch and adapt GXT further?
Or should I progressively migrate everything to native GWT widgets (like Composite, DataGrid,  etc.)?

Has anyone gone through a similar migration? Are all these issues common when trying to use a patched GXT with GWT 2.10?

Any advice or shared experience would be super appreciated!

Thanks a lot 

wejden

Le dimanche 23 mars 2025 à 20:26:32 UTC+1, Colin Alworth a écrit :
#1 I think Jens covers it well - something is almost certainly wrong with your modified jar or how the classpath is built.

For #2, the "-server" argument lets you specify a com.google.gwt.core.ext.ServletContainerLauncher type, so org.eclipse.jetty.server.Server will not suffice. If you do not specify one, as of GWT 2.12 the old default of com.google.gwt.dev.shell.jetty.JettyLauncher (using a wrapped Jetty 9) is still used, which is what it sounds like you want anyway. This will change in the future, see https://github.com/gwtproject/gwt/issues/10057 and linked issues, If you're interested in something newer than the default Jetty 9, also see https://groups.google.com/g/google-web-toolkit/c/3dSoHpHD5jY/m/faAeQeJ-AwAJ and https://groups.google.com/g/google-web-toolkit-contributors/c/7jvGVaiSUdI.

Note that Jetty 9 sometimes doesn't behave nicely when it tries to scan your classpath - if it finds something that it can't understand while looking for annotations, it will break. This will result in an error something like
java.lang.IllegalArgumentException: Unsupported class file major version 64
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:199)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:180)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:166)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:287)
at org.eclipse.jetty.annotations.AnnotationParser.scanClass(AnnotationParser.java:932)
at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:734)
... 6 more


#3, nothing special should be required - besides the wrong instance passed to -server, what errors are you seeing?

Re your note: you should not need to deploy a complete war to tomcat for local development - the best way to think about this is "If I wasn't using GWT, how would I want to debug my server", then amend that slightly to permit SDM to change files in the same sort of way that you would either manually edit JS/HTML or you'd use a tool like npm/etc.

On Sunday, March 23, 2025 at 3:23:07 AM UTC-5 wejden...@gmail.com wrote:

Hello!  

I am following your conversation because i am working on same issues :    

Migrating GWT/GXT project to GWT 2.10 + Java 11 + Jetty 9

Initial Context on Legacy project using:

  • GWT 2.8.2

  • GXT 2.3.1a-gwt22

  • Embedded Jetty

  • Java 8

Migration Goal

Update the project to use:

  • Java 11

  • GWT 2.10.1

  • Jetty 9

  • A custom-built GXT version compatible with GWT 2.10

Steps Already Completed 

1. GXT Recompilation and Installation

  • Cloned the GXT 2.3.1a sources.

  • Adapted the code to compile with GWT 2.10.1.

  • Successfully built gxt-main-2.3.1a-gwt2.10.jar.

  • Installed it locally using:


2. Maven Configuration Updated

  • Switched to Java 11 using maven.compiler.source and target.

  • GWT updated to version 2.10.1.

  • Added the locally installed GXT dependency

3. GWT Module Inheritance Added
4. GXT Verification

  • Confirmed GXT.gwt.xml is present inside the JAR (jar tf checked).

  • JAR added to the Eclipse launch configuration (Run Configurations > Classpath).

Jetty Configuration Jetty 9 Already in Use

  • Version confirmed: 9.4.52.v20230823 (via mvn dependency:tree).

  • Dependencies have <scope>compile</scope> (not provided).

  • jetty-server-9.4.52.v20230823.jar appears in the Eclipse classpath.


Current Blocking Issues

1. GXT Not Found at Runtime

When launching GWT DevMode: Unable to find 'com/extjs/gxt/ui/GXT.gwt.xml' on your classpath

Despite:

  • The file being present in the JAR.

  • The JAR being listed in the Run Configurations > Classpath.

  • Proper inheritance in the .gwt.xml file.

2. Jetty Server Class Not Found

Tried using the argument:

-server org.eclipse.jetty.server.Server

ClassNotFoundException: org.eclipse.jetty.server.Server

Even though the JAR is present in the classpath, and Jetty 9 is confirmed to be in use.

So i need to understand

  1. Why is GWT DevMode (or CodeServer) unable to find com.extjs.gxt.ui.GXT.gwt.xml, even though it is present and properly declared?

  2. How can I resolve the ClassNotFoundException for org.eclipse.jetty.server.Server, despite Jetty 9 being correctly added?

  3. Are there any special configurations or recommendations for running GWT 2.10 with Jetty 9 and Java 11 in Eclipse?

Important note: I do not want to switch to a Tomcat 9 deployment (war packaging) as a workaround. The current state of the project makes the packaging and deployment process extremely slow — over one hour just to build and deploy. Therefore, I need a solution that works using GWT Super DevMode and embedded Jetty

Thanks in advance for any help or suggestions.


__wejden



Le mercredi 12 mars 2025 à 17:32:47 UTC+1, Jens a écrit :
As Colin said you can use @WebServlet and enable configuration via annotation scanning in your servlet container. However if your application is large then scanning might slow your deployment down. If deployment time is not a concern then it is the easiest solution. There are additional annotations for other classes you normally add to your web.xml.

If you don't like class scanning during deployment time you can write an annotation processor that picks up all these @WebServlet annotated servlets and generates a class that registers them using the ServletContext API. Then you use that generated class in a custom ServletContextListener implementation to register everything. That ServletContextListener would then be the only entry in your web.xml. Alternatively, if you use Jetty as servlet container you can use Jetty's quickstart module to let it generate a web.xml by scanning your code once (as part of the build process).

-- J.



--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.


--
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-tool...@googlegroups.com.


--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.


--
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-tool...@googlegroups.com.

--
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-tool...@googlegroups.com.


--
Best Regards,
Wejden MRABTI

Ingénieur étude et développement

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/56edc394-c92f-4cf8-aab4-08b7caf3137dn%40googlegroups.com.
Posted by at No comments:
Subscribe to: Posts (Atom)