Thursday, April 30, 2026

Re: GWT Deferred Binding Error – UiBinder Not Resolved from Dependent Module (phoenix-air)

Did you fix the error with your MonitorServiceInterfaceProxyGenerator?

On Thursday, 30 April 2026 at 7:01:30 pm UTC+10 Arpan Ameta wrote:
Hello All,

Anyone can please help us...??

On Wednesday, March 25, 2026 at 12:13:19 PM UTC+5:30 Arpan Ameta wrote:
Screenshot 2026-03-25 120849.pngScreenshot 2026-03-25 120822.png

Hi Craig,

Thanks for pointing that out.

Yes, in the screenshot I shared, there is indeed an error related to MonitorServiceInterfaceProxyGenerator. However, this is a custom generator used across multiple modules in our project, and those modules are compiling and working fine even after the upgrade.

That’s why I’m a bit unsure if this generator is the root cause here, or if it’s just a side effect of something failing earlier in the compilation chain.

Also, the failure still surfaces specifically at:

AwbCustomer.AwbCustomerUiBinder

which makes it look like a UiBinder deferred binding issue at first glance.

That said, I agree with your point — if the generator fails, it could potentially break the binding process. I’ll try isolating this further by:

  • Checking if this module has any differences in how the generator is used
  • Verifying if any recent changes or stricter rules in GWT 2.12.0 / JDK 17 are affecting it
  • Temporarily disabling or bypassing the generator (if possible) to see if the error persists

I’ll update once I have more findings.

Thanks again for your help!

On Wednesday, March 25, 2026 at 4:33:36 AM UTC+5:30 Craig Mitchell wrote:
Is your screenshot saying there is an error with the MonitorServiceInterfaceProxyGenerator?  I've no clue what that is, but that error could be causing the error with the AwbCustomer.

On Tuesday, 24 March 2026 at 10:56:33 pm UTC+11 Arpan Ameta wrote:
Screenshot 2026-03-24 165332.pngScreenshot 2026-03-24 172248.pngScreenshot 2026-03-24 165414.png

Hi Craig,

Thanks for your response.

Yes, the error occurs during compilation (GWT Code Server / compile), but interestingly I do not see the “Unable to find resource” error for the AwbCustomer.ui.xml file.

The .ui.xml file is present in the correct package and follows the same naming convention as other working modules. That’s why this is a bit confusing — if it were a missing or misplaced file, I would expect that specific error to show up.

In this case, the compilation fails directly with the deferred binding error:

Failed to resolve 'AwbCustomer.AwbCustomerUiBinder' via deferred binding

Also worth noting:

  • Other UiBinder classes in different modules are compiling fine
  • This issue started only after upgrading to GWT 2.12.0 and JDK 17
  • The structure and setup of this module is consistent with others that are working

Because of this, I’m wondering if this could be related to stricter checks in the newer GWT version or something subtle being missed in this particular class/module.

Please let me know if there’s anything specific you’d recommend checking beyond the usual .ui.xml placement — happy to dig deeper.

Thanks again for your help!

On Tuesday, March 24, 2026 at 2:53:06 PM UTC+5:30 Craig Mitchell wrote:
I assume you get this error when running, and the GWT Code Server fails to compile that class.

If you've misspelt or misplaced the ui.xml file, you should also get an error like:

[ERROR] Unable to find resource: blah/blah/.../AwbCustomer.ui.xml

Do you see that error?
On Tuesday, 24 March 2026 at 5:58:33 pm UTC+11 Arpan Ameta wrote:

Hi Team,

I’m currently facing an issue after upgrading our project to GWT 2.12.0 and JDK 17, and I’d really appreciate any guidance or suggestions from the community.

While most of our modules are compiling and working fine post-upgrade, one specific module is failing during GWT compilation with the following error:

[ERROR] Failed to resolve 'com.shipco.air.modules.awb.client.airimport.view.awbpopup.AwbCustomer.AwbCustomerUiBinder' via deferred binding

From the logs, it appears to be a UiBinder-related issue during deferred binding. The same pattern and structure are used in other modules, and they are working without any problems.

A few points to highlight:

  • This issue started only after upgrading to GWT 2.12.0 and JDK 17
  • Other UiBinder-based components in different modules are compiling successfully
  • The .ui.xml file exists and is correctly placed
  • Module inheritance and source paths appear to be properly configured
  • There is also a custom generator involved (MonitorServiceInterfaceProxyGenerator), though it's used elsewhere without issues

At this point, I’m unsure whether this is:

  • A compatibility issue with GWT 2.12.0 or JDK 17
  • A stricter validation introduced in newer versions
  • Or something specific being missed in this module

If anyone has encountered a similar issue or has suggestions on what to check next, your help would be greatly appreciated.

Thanks in advance for your support!

On Friday, March 20, 2026 at 6:18:18 PM UTC+5:30 Thomas Broyer wrote:


On Friday, March 20, 2026 at 1:19:56 PM UTC+1 arpanam...@gmail.com wrote:

>   * Maven build with net.ltgt.gwt.maven:gwt-maven-plugin
> ----


> Any insights or best practices for structuring GWT modules across Maven projects would be really helpful.

For a client-only library, use `<packaging>gwt-lib</packaging>`, and then depend on it using <type>gwt-lib</type> for better running/debugging support: https://tbroyer.github.io/gwt-maven-plugin/codeserver.html

--
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/a0b1224e-3817-42ac-8597-0ba2f8ce2f18n%40googlegroups.com.

Re: GWT Deferred Binding Error – UiBinder Not Resolved from Dependent Module (phoenix-air)

Hello All,

Anyone can please help us...??

On Wednesday, March 25, 2026 at 12:13:19 PM UTC+5:30 Arpan Ameta wrote:
Screenshot 2026-03-25 120849.pngScreenshot 2026-03-25 120822.png

Hi Craig,

Thanks for pointing that out.

Yes, in the screenshot I shared, there is indeed an error related to MonitorServiceInterfaceProxyGenerator. However, this is a custom generator used across multiple modules in our project, and those modules are compiling and working fine even after the upgrade.

That’s why I’m a bit unsure if this generator is the root cause here, or if it’s just a side effect of something failing earlier in the compilation chain.

Also, the failure still surfaces specifically at:

AwbCustomer.AwbCustomerUiBinder

which makes it look like a UiBinder deferred binding issue at first glance.

That said, I agree with your point — if the generator fails, it could potentially break the binding process. I’ll try isolating this further by:

  • Checking if this module has any differences in how the generator is used
  • Verifying if any recent changes or stricter rules in GWT 2.12.0 / JDK 17 are affecting it
  • Temporarily disabling or bypassing the generator (if possible) to see if the error persists

I’ll update once I have more findings.

Thanks again for your help!

On Wednesday, March 25, 2026 at 4:33:36 AM UTC+5:30 Craig Mitchell wrote:
Is your screenshot saying there is an error with the MonitorServiceInterfaceProxyGenerator?  I've no clue what that is, but that error could be causing the error with the AwbCustomer.

On Tuesday, 24 March 2026 at 10:56:33 pm UTC+11 Arpan Ameta wrote:
Screenshot 2026-03-24 165332.pngScreenshot 2026-03-24 172248.pngScreenshot 2026-03-24 165414.png

Hi Craig,

Thanks for your response.

Yes, the error occurs during compilation (GWT Code Server / compile), but interestingly I do not see the “Unable to find resource” error for the AwbCustomer.ui.xml file.

The .ui.xml file is present in the correct package and follows the same naming convention as other working modules. That’s why this is a bit confusing — if it were a missing or misplaced file, I would expect that specific error to show up.

In this case, the compilation fails directly with the deferred binding error:

Failed to resolve 'AwbCustomer.AwbCustomerUiBinder' via deferred binding

Also worth noting:

  • Other UiBinder classes in different modules are compiling fine
  • This issue started only after upgrading to GWT 2.12.0 and JDK 17
  • The structure and setup of this module is consistent with others that are working

Because of this, I’m wondering if this could be related to stricter checks in the newer GWT version or something subtle being missed in this particular class/module.

Please let me know if there’s anything specific you’d recommend checking beyond the usual .ui.xml placement — happy to dig deeper.

Thanks again for your help!

On Tuesday, March 24, 2026 at 2:53:06 PM UTC+5:30 Craig Mitchell wrote:
I assume you get this error when running, and the GWT Code Server fails to compile that class.

If you've misspelt or misplaced the ui.xml file, you should also get an error like:

[ERROR] Unable to find resource: blah/blah/.../AwbCustomer.ui.xml

Do you see that error?
On Tuesday, 24 March 2026 at 5:58:33 pm UTC+11 Arpan Ameta wrote:

Hi Team,

I’m currently facing an issue after upgrading our project to GWT 2.12.0 and JDK 17, and I’d really appreciate any guidance or suggestions from the community.

While most of our modules are compiling and working fine post-upgrade, one specific module is failing during GWT compilation with the following error:

[ERROR] Failed to resolve 'com.shipco.air.modules.awb.client.airimport.view.awbpopup.AwbCustomer.AwbCustomerUiBinder' via deferred binding

From the logs, it appears to be a UiBinder-related issue during deferred binding. The same pattern and structure are used in other modules, and they are working without any problems.

A few points to highlight:

  • This issue started only after upgrading to GWT 2.12.0 and JDK 17
  • Other UiBinder-based components in different modules are compiling successfully
  • The .ui.xml file exists and is correctly placed
  • Module inheritance and source paths appear to be properly configured
  • There is also a custom generator involved (MonitorServiceInterfaceProxyGenerator), though it's used elsewhere without issues

At this point, I’m unsure whether this is:

  • A compatibility issue with GWT 2.12.0 or JDK 17
  • A stricter validation introduced in newer versions
  • Or something specific being missed in this module

If anyone has encountered a similar issue or has suggestions on what to check next, your help would be greatly appreciated.

Thanks in advance for your support!

On Friday, March 20, 2026 at 6:18:18 PM UTC+5:30 Thomas Broyer wrote:


On Friday, March 20, 2026 at 1:19:56 PM UTC+1 arpanam...@gmail.com wrote:

>   * Maven build with net.ltgt.gwt.maven:gwt-maven-plugin
> ----


> Any insights or best practices for structuring GWT modules across Maven projects would be really helpful.

For a client-only library, use `<packaging>gwt-lib</packaging>`, and then depend on it using <type>gwt-lib</type> for better running/debugging support: https://tbroyer.github.io/gwt-maven-plugin/codeserver.html

--
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/7df80812-a37b-4946-957b-5591494f8415n%40googlegroups.com.

Thursday, April 16, 2026

Re: Build warning

Thanks, I have created an issue for it: https://github.com/gwtproject/gwt/issues/10309

-- J.

Mirza Hadžič schrieb am Donnerstag, 16. April 2026 um 15:41:41 UTC+2:
Hi,

Java 26 with GWT 2.13 has this warnig:

WARNING: Final field map in class
com.google.gwt.thirdparty.guava.common.collect.ImmutableMultimap has
been mutated reflectively by class
com.google.gwt.thirdparty.guava.common.collect.Serialization$FieldSetter
in unnamed module @74e52303 (fi

Mirza

--
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/3b7b65b4-7857-4588-95ca-43109595d31bn%40googlegroups.com.

Build warning

Hi, Java 26 with GWT 2.13 has this warnig: WARNING: Final field map in class com.google.gwt.thirdparty.guava.common.collect.ImmutableMultimap has been mutated reflectively by class com.google.gwt.thirdparty.guava.common.collect.Serialization$FieldSetter in unnamed module @74e52303 (fi Mirza -- 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/6501a164-70db-4666-9f5d-6c9e2a0a0709%40digitech.cz.

Tuesday, April 14, 2026

Re: Per-module launcherDir using gwt-maven-plugin



On Tuesday, April 14, 2026 at 10:18:49 AM UTC+2 beussl...@gmail.com wrote:
Also I've a question wrt plugin usage, it looks like if I've A → B → C dependencies with A & B being gwt-lib-packaged and C gwt-app, I have to declare A as regular and classifier:sources dependency in B in order for A to be correctly picked up when launching codeServer on C, using <type>gwt-lib</type> on transitive dependencies does not seem to work as sources are not found. Did I, again, miss something?

AFAIR, this should work.
It seems to work within the https://github.com/tbroyer/gwt-maven-plugin/tree/main/src/it/e2e integration test (clone the repo, checkout the 1.2.0 tag, run mvn clean verify, go to target/it-tests/e2e, run mvn gwt:codeserver -X, notice that it does print some ignored dependencies –due to the way projects are setup, but this might also not trigger the issue–, but the -src in the arguments are OK, then call http://127.0.0.1:9876/recompile/e2e?user.agent=safari to trigger a compilation and all goes well; this can be checked by opening http://127.0.0.1:9876/e2e/ in a browser)

Can you create a repro and open an issue?
(feel free to use the e2e integration test as a starting point, at least regarding the Java/GWT code)

--
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/1e54365f-9e7a-447c-a380-6be3a8dca6a0n%40googlegroups.com.

Re: Per-module launcherDir using gwt-maven-plugin

Hi Thomas
Thank you for your hint, there was indeed a launcherDir in the root pom.xml (the -DLauncherDir was a typo in the message, not in the commande). Using -DlauncherDir works perfectly. I think I'll rely on properties with provided scripts to launch codeServer rather then execuitonsIds since this does the jobs and does not involve some strange Voodoo tricks :-)
Also I've a question wrt plugin usage, it looks like if I've A → B → C dependencies with A & B being gwt-lib-packaged and C gwt-app, I have to declare A as regular and classifier:sources dependency in B in order for A to be correctly picked up when launching codeServer on C, using <type>gwt-lib</type> on transitive dependencies does not seem to work as sources are not found. Did I, again, miss something?
Kind regards

Le lundi 13 avril 2026 à 17:38:22 UTC+2, Thomas Broyer a écrit :
On Monday, April 13, 2026 at 1:58:41 PM UTC+2 beussl...@gmail.com wrote:
Hi group,
We've a pretty large multimodule projet which delivers two wars with different server code. One of the war includes 3 gwt apps and the other one 1 gwt app (4 applications total).
I was wondering if there was a way to configure a separate launcherDir for the fourth application. Given the fact that it's done in root pom I'm assuming I'll have to rely on properties but if there's a better way I'd be happy to use it

I think I would declare 2 <execution>s (one of them could use the default-cli executionId), each with its own <launcherDir>, and either <modules> or <projects>, and then run "mvn gwt:codeserver@foo" and "mvn gwt:codeserver@bar"
 
By the way, passing -DLauncherDir on the CLI does not seem to have any effect on the generated command line

Besides that it's -DlauncherDir rather than -DLauncherDir (lowercase L), that can only work if you do not have a <launcherDir> configured in your POM. You should be able to experiment with the above by removing most configuration in the root POM and then running "mvn gwt:codeserver -DlauncherDir=… -Dgwt.projects=…"

--
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/5f33ee79-faca-4810-a30f-9d257e2e7201n%40googlegroups.com.

Monday, April 13, 2026

Re: Per-module launcherDir using gwt-maven-plugin



On Monday, April 13, 2026 at 1:58:41 PM UTC+2 beussl...@gmail.com wrote:
Hi group,
We've a pretty large multimodule projet which delivers two wars with different server code. One of the war includes 3 gwt apps and the other one 1 gwt app (4 applications total).
I was wondering if there was a way to configure a separate launcherDir for the fourth application. Given the fact that it's done in root pom I'm assuming I'll have to rely on properties but if there's a better way I'd be happy to use it

I think I would declare 2 <execution>s (one of them could use the default-cli executionId), each with its own <launcherDir>, and either <modules> or <projects>, and then run "mvn gwt:codeserver@foo" and "mvn gwt:codeserver@bar"
 
By the way, passing -DLauncherDir on the CLI does not seem to have any effect on the generated command line

Besides that it's -DlauncherDir rather than -DLauncherDir (lowercase L), that can only work if you do not have a <launcherDir> configured in your POM. You should be able to experiment with the above by removing most configuration in the root POM and then running "mvn gwt:codeserver -DlauncherDir=… -Dgwt.projects=…"

--
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/00a727c6-7073-4c98-bc40-367e4d1651cdn%40googlegroups.com.