Re: Re-loading back-end code while system is running

I noticed that you can change front-end code without rebooting the system and rebuilding.  However, this doesn't seem true about the back-end code.  Am I missing something?

Going forward GWT will only provide a simple server to serve static files out of the box. If you want DevMode to launch an application server for your server side code you have to use "-server com.google.gwt.dev.shell.JettyLauncher" to get the implementation GWT had always provided (but it will be removed in a future release) or provide your own implementation of GWTs "ServletContainerLauncher".  If you use a proper build tool with separated modules for GWT code and for server code you usually already have some mechanism to launch your app server. Also the coupling GWT did before always produced classpath issues. 

So going forward it is up to the developer to serve the backend code.

 

Also, since I originally used GWT, I have learned HTML, CSS, JavaScript, etc.  Now I feel like it is easier to specify layout in HTML/CSS than using all of that GWT Java code.  GWT front-end code seems incredibly verbose.  That leads me to two questions:

1. Can I use HTML/CSS?  If so, are there examples?

GWT SDK provides UiBinder which allows you to write XML documents with a matching Java class and GWT will generate an additional Java class from the XML document to glue both together, see: https://www.gwtproject.org/doc/latest/DevGuideUiBinder.html

It is still a bit verbose compared to JS frameworks which support two way databinding and plain HTML but it is good enough if you like to read HTML instead of code.

 

2. Is there a graphical GUI system that allows someone to graphically design an interface and have it generate all of that Java code for the front-end?

There was an Eclipse plugin called GWT Designer, but I think it does not work anymore. I am not aware of anything else. Your best bet is probably using UiBinder XML and some AI help.

 

Lastly, and just FYI, in response to what Google did with GWT at that time, I ended up writing my own open-source, full-stack web development framework.  In addition to being able to change front-end code while developing, it also supports changing back-end code without having to reboot the server or recompile anything.  It also has built-in support for microservices, REST (actually JSON-RPC), authentication, custom HTML controls, SQL API, reporting, CSV import/export, crypto, LLM interfaces, and a lot more.  It has been used in production systems for a few years now.  It's at kissweb.org

Sounds interesting. 

For GWT related libraries you can take a look at https://github.com/gwtboot/gwt-boot-awesome-lili

-- J.

--
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/b64a93d2-a14f-495f-b9b3-514d3db71afen%40googlegroups.com.

Re-loading back-end code while system is running

Greetings,

I built an app in GWT back when Google was developing it.  It worked okay and avoided HTML & CSS, which I didn't know at that time.  When Google dropped browser support for GWT, I dropped GWT.

Out of curiosity, I downloaded the latest GWT.  Interesting.  I see you've solved the front-end debugging issues.  Nice!

I noticed that you can change front-end code without rebooting the system and rebuilding.  However, this doesn't seem true about the back-end code.  Am I missing something?

Also, since I originally used GWT, I have learned HTML, CSS, JavaScript, etc.  Now I feel like it is easier to specify layout in HTML/CSS than using all of that GWT Java code.  GWT front-end code seems incredibly verbose.  That leads me to two questions:

1. Can I use HTML/CSS?  If so, are there examples?

2. Is there a graphical GUI system that allows someone to graphically design an interface and have it generate all of that Java code for the front-end?

Lastly, and just FYI, in response to what Google did with GWT at that time, I ended up writing my own open-source, full-stack web development framework.  In addition to being able to change front-end code while developing, it also supports changing back-end code without having to reboot the server or recompile anything.  It also has built-in support for microservices, REST (actually JSON-RPC), authentication, custom HTML controls, SQL API, reporting, CSV import/export, crypto, LLM interfaces, and a lot more.  It has been used in production systems for a few years now.  It's at kissweb.org

Thanks!

Blake McBride

--
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/CABwHSOsAw%3DE2ih0_ghTNR%2B70YqSu2P1LFzvjG5Zt9E8xAWO2jA%40mail.gmail.com.

Re: GWT Code Server Jetty Mismatch

Awesome!  Thanks Colin.  Yes, moving the spring-boot-dependencies from the top level, into the server module, fixes it.  🎉

On Sunday, 15 February 2026 at 4:07:51 am UTC+11 eliasb...@gmail.com wrote:

I am aligned with controlling the transitive dependencies versions on a top level module, as I faced such complexities and used the same approach, in groups of solutions.

Particularly with overlapping dependency chains and SpringBoot , I had to override the Jetty versions among others in parent Maven modules.

I am guessing Gradle can do similar but I think it is known for its fragility in my point of view.

I hope this helps.

On Saturday, 14 February 2026 at 15:51:28 UTC Colin Alworth wrote:

That's an irritating outcome for sure - though updating GWT to Jetty 12.1.5 only punts on the issue, since the next time Spring Boot wants a different Jetty version (or some other library) we end up back in this mess (though likely with a much more subtle failure mode).

Gradle does a much better job at letting you break up classpaths here, at the cost of dramatically increased complexity in the worst case - but it could allow you to specify each bom in its own classpath configuration, rather than mix the two together.

I think I have a solution that works for your project, but I'm going to try to reason it out here a bit, so someone can poke holes in my logic:

• The GWT wiring here is configured for the parent project pom, so that the plugin can run from there if desired. 
• The server BOM is also declared in the parent project pom, so that we just have it in one place. This probably makes sense for large enough projects where it needs to be reused - but at least for this project it seems unnecessary.

What I did was to move the jetty bom into test-server:
diff --git a/pom.xml b/pom.xml
index bb3edc3..ae118dc 100644
--- a/pom.xml
+++ b/pom.xml
@@ -24,13 +24,6 @@
         <type>pom</type>
         <scope>import</scope>
       </dependency>
-      <dependency>
-        <groupId>org.springframework.boot</groupId>
-        <artifactId>spring-boot-dependencies</artifactId>
-        <version>${spring-boot.version}</version>
-        <type>pom</type>
-        <scope>import</scope>
-      </dependency>
       <dependency>
         <groupId>org.yaml</groupId>
         <artifactId>snakeyaml</artifactId>
diff --git a/test-server/pom.xml b/test-server/pom.xml
index 6dbf708..31426c0 100644
--- a/test-server/pom.xml
+++ b/test-server/pom.xml
@@ -16,6 +16,17 @@
     <maven.compiler.target>17</maven.compiler.target>
   </properties>
 
+  <dependencyManagement>
+    <dependencies>
+      <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-dependencies</artifactId>
+        <version>${spring-boot.version}</version>
+        <type>pom</type>
+        <scope>import</scope>
+      </dependency>
+    </dependencies>
+  </dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>${project.groupId}</groupId>

Then, I was able to build and start the server, and start the devmode server. I did not go so far as to make changes yet, but I'm not familiar with how spring boot likes to work for "dev" mode.

On Friday, February 13, 2026 at 4:55:11 PM UTC-6 ma...@craig-mitchell.com wrote:

I raised a Spring Boot Jetty issue https://github.com/spring-projects/spring-boot/issues/49220 because I thought there was an issue with Jetty.

Turns out, the GWT Code Server is bringing in an old version of Jetty which breaks Spring Boot.

When I tell Spring Boot to use the version of Jetty it wants, the GWT Code Server then breaks with the error:

[WARNING] java.lang.NoClassDefFoundError: org/eclipse/jetty/server/handler/ContextHandler$Context
[WARNING]       at com.google.gwt.dev.codeserver.WebServer.start(WebServer.java:125)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:162)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:104)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:55)
[WARNING] Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.server.handler.ContextHandler$Context
[WARNING]       at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
[WARNING]       at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
[WARNING]       at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
[WARNING]       ... 4 more
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for test 1.0-SNAPSHOT:
[INFO]
[INFO] test ............................................... FAILURE [  4.688 s]
[INFO] test-shared ........................................ SKIPPED
[INFO] test-client ........................................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.436 s
[INFO] Finished at: 2026-02-14T09:25:21+11:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal net.ltgt.gwt.maven:gwt-maven-plugin:1.2.0:codeserver (default-cli) on project test: Process exited with an error: 1 (Exit value: 1) -> [Help 1]

Is there a way to allow Spring Boot to use Jetty 12.1.5, but also let the GWT Code Server use Jetty 9.4.58?

(Apologies if this has been asked before, I searched around and couldn't find it)

--
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/7e499e41-4180-43cb-87ac-ddb7cbd3297en%40googlegroups.com.

Re: GWT Code Server Jetty Mismatch

I am aligned with controlling the transitive dependencies versions on a top level module, as I faced such complexities and used the same approach, in groups of solutions.

Particularly with overlapping dependency chains and SpringBoot , I had to override the Jetty versions among others in parent Maven modules.

I am guessing Gradle can do similar but I think it is known for its fragility in my point of view.

I hope this helps.

On Saturday, 14 February 2026 at 15:51:28 UTC Colin Alworth wrote:

That's an irritating outcome for sure - though updating GWT to Jetty 12.1.5 only punts on the issue, since the next time Spring Boot wants a different Jetty version (or some other library) we end up back in this mess (though likely with a much more subtle failure mode).

Gradle does a much better job at letting you break up classpaths here, at the cost of dramatically increased complexity in the worst case - but it could allow you to specify each bom in its own classpath configuration, rather than mix the two together.

I think I have a solution that works for your project, but I'm going to try to reason it out here a bit, so someone can poke holes in my logic:

• The GWT wiring here is configured for the parent project pom, so that the plugin can run from there if desired. 
• The server BOM is also declared in the parent project pom, so that we just have it in one place. This probably makes sense for large enough projects where it needs to be reused - but at least for this project it seems unnecessary.

What I did was to move the jetty bom into test-server:
diff --git a/pom.xml b/pom.xml
index bb3edc3..ae118dc 100644
--- a/pom.xml
+++ b/pom.xml
@@ -24,13 +24,6 @@
         <type>pom</type>
         <scope>import</scope>
       </dependency>
-      <dependency>
-        <groupId>org.springframework.boot</groupId>
-        <artifactId>spring-boot-dependencies</artifactId>
-        <version>${spring-boot.version}</version>
-        <type>pom</type>
-        <scope>import</scope>
-      </dependency>
       <dependency>
         <groupId>org.yaml</groupId>
         <artifactId>snakeyaml</artifactId>
diff --git a/test-server/pom.xml b/test-server/pom.xml
index 6dbf708..31426c0 100644
--- a/test-server/pom.xml
+++ b/test-server/pom.xml
@@ -16,6 +16,17 @@
     <maven.compiler.target>17</maven.compiler.target>
   </properties>
 
+  <dependencyManagement>
+    <dependencies>
+      <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-dependencies</artifactId>
+        <version>${spring-boot.version}</version>
+        <type>pom</type>
+        <scope>import</scope>
+      </dependency>
+    </dependencies>
+  </dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>${project.groupId}</groupId>

Then, I was able to build and start the server, and start the devmode server. I did not go so far as to make changes yet, but I'm not familiar with how spring boot likes to work for "dev" mode.

On Friday, February 13, 2026 at 4:55:11 PM UTC-6 ma...@craig-mitchell.com wrote:

I raised a Spring Boot Jetty issue https://github.com/spring-projects/spring-boot/issues/49220 because I thought there was an issue with Jetty.

Turns out, the GWT Code Server is bringing in an old version of Jetty which breaks Spring Boot.

When I tell Spring Boot to use the version of Jetty it wants, the GWT Code Server then breaks with the error:

[WARNING] java.lang.NoClassDefFoundError: org/eclipse/jetty/server/handler/ContextHandler$Context
[WARNING]       at com.google.gwt.dev.codeserver.WebServer.start(WebServer.java:125)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:162)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:104)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:55)
[WARNING] Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.server.handler.ContextHandler$Context
[WARNING]       at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
[WARNING]       at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
[WARNING]       at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
[WARNING]       ... 4 more
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for test 1.0-SNAPSHOT:
[INFO]
[INFO] test ............................................... FAILURE [  4.688 s]
[INFO] test-shared ........................................ SKIPPED
[INFO] test-client ........................................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.436 s
[INFO] Finished at: 2026-02-14T09:25:21+11:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal net.ltgt.gwt.maven:gwt-maven-plugin:1.2.0:codeserver (default-cli) on project test: Process exited with an error: 1 (Exit value: 1) -> [Help 1]

Is there a way to allow Spring Boot to use Jetty 12.1.5, but also let the GWT Code Server use Jetty 9.4.58?

(Apologies if this has been asked before, I searched around and couldn't find it)

--
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/1add89dd-49dc-47c0-b3dd-010dc94f1db3n%40googlegroups.com.

Re: GWT Code Server Jetty Mismatch

That's an irritating outcome for sure - though updating GWT to Jetty 12.1.5 only punts on the issue, since the next time Spring Boot wants a different Jetty version (or some other library) we end up back in this mess (though likely with a much more subtle failure mode).

Gradle does a much better job at letting you break up classpaths here, at the cost of dramatically increased complexity in the worst case - but it could allow you to specify each bom in its own classpath configuration, rather than mix the two together.

I think I have a solution that works for your project, but I'm going to try to reason it out here a bit, so someone can poke holes in my logic:

• The GWT wiring here is configured for the parent project pom, so that the plugin can run from there if desired. 
• The server BOM is also declared in the parent project pom, so that we just have it in one place. This probably makes sense for large enough projects where it needs to be reused - but at least for this project it seems unnecessary.

What I did was to move the jetty bom into test-server:
diff --git a/pom.xml b/pom.xml
index bb3edc3..ae118dc 100644
--- a/pom.xml
+++ b/pom.xml
@@ -24,13 +24,6 @@
         <type>pom</type>
         <scope>import</scope>
       </dependency>
-      <dependency>
-        <groupId>org.springframework.boot</groupId>
-        <artifactId>spring-boot-dependencies</artifactId>
-        <version>${spring-boot.version}</version>
-        <type>pom</type>
-        <scope>import</scope>
-      </dependency>
       <dependency>
         <groupId>org.yaml</groupId>
         <artifactId>snakeyaml</artifactId>
diff --git a/test-server/pom.xml b/test-server/pom.xml
index 6dbf708..31426c0 100644
--- a/test-server/pom.xml
+++ b/test-server/pom.xml
@@ -16,6 +16,17 @@
     <maven.compiler.target>17</maven.compiler.target>
   </properties>
 
+  <dependencyManagement>
+    <dependencies>
+      <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-dependencies</artifactId>
+        <version>${spring-boot.version}</version>
+        <type>pom</type>
+        <scope>import</scope>
+      </dependency>
+    </dependencies>
+  </dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>${project.groupId}</groupId>

Then, I was able to build and start the server, and start the devmode server. I did not go so far as to make changes yet, but I'm not familiar with how spring boot likes to work for "dev" mode.

On Friday, February 13, 2026 at 4:55:11 PM UTC-6 ma...@craig-mitchell.com wrote:

I raised a Spring Boot Jetty issue https://github.com/spring-projects/spring-boot/issues/49220 because I thought there was an issue with Jetty.

Turns out, the GWT Code Server is bringing in an old version of Jetty which breaks Spring Boot.

When I tell Spring Boot to use the version of Jetty it wants, the GWT Code Server then breaks with the error:

[WARNING] java.lang.NoClassDefFoundError: org/eclipse/jetty/server/handler/ContextHandler$Context
[WARNING]       at com.google.gwt.dev.codeserver.WebServer.start(WebServer.java:125)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:162)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:104)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:55)
[WARNING] Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.server.handler.ContextHandler$Context
[WARNING]       at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
[WARNING]       at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
[WARNING]       at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
[WARNING]       ... 4 more
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for test 1.0-SNAPSHOT:
[INFO]
[INFO] test ............................................... FAILURE [  4.688 s]
[INFO] test-shared ........................................ SKIPPED
[INFO] test-client ........................................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.436 s
[INFO] Finished at: 2026-02-14T09:25:21+11:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal net.ltgt.gwt.maven:gwt-maven-plugin:1.2.0:codeserver (default-cli) on project test: Process exited with an error: 1 (Exit value: 1) -> [Help 1]

Is there a way to allow Spring Boot to use Jetty 12.1.5, but also let the GWT Code Server use Jetty 9.4.58?

(Apologies if this has been asked before, I searched around and couldn't find it)

--
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/2f128241-5531-4b88-9fb8-c1fa50aac333n%40googlegroups.com.

GWT Code Server Jetty Mismatch

I raised a Spring Boot Jetty issue https://github.com/spring-projects/spring-boot/issues/49220 because I thought there was an issue with Jetty.

Turns out, the GWT Code Server is bringing in an old version of Jetty which breaks Spring Boot.

When I tell Spring Boot to use the version of Jetty it wants, the GWT Code Server then breaks with the error:

[WARNING] java.lang.NoClassDefFoundError: org/eclipse/jetty/server/handler/ContextHandler$Context
[WARNING]       at com.google.gwt.dev.codeserver.WebServer.start(WebServer.java:125)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:162)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:104)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:55)
[WARNING] Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.server.handler.ContextHandler$Context
[WARNING]       at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
[WARNING]       at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
[WARNING]       at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
[WARNING]       ... 4 more
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for test 1.0-SNAPSHOT:
[INFO]
[INFO] test ............................................... FAILURE [  4.688 s]
[INFO] test-shared ........................................ SKIPPED
[INFO] test-client ........................................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.436 s
[INFO] Finished at: 2026-02-14T09:25:21+11:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal net.ltgt.gwt.maven:gwt-maven-plugin:1.2.0:codeserver (default-cli) on project test: Process exited with an error: 1 (Exit value: 1) -> [Help 1]

Is there a way to allow Spring Boot to use Jetty 12.1.5, but also let the GWT Code Server use Jetty 9.4.58?

(Apologies if this has been asked before, I searched around and couldn't find it)

--
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/08339070-ee36-46d8-8fda-ba995d3c8ae2n%40googlegroups.com.

Re: Inject nocache.js into the main index.html

Good point Jens.  Here's some handy code that works well for me:

In the HttpServlet that servers up the index.html file:

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
  String serverVersion =  [LOAD YOUR SERVER VERSION]
  String quotedETag = "\"" + serverVersion + "\"";

  response.setHeader("ETag", quotedETag);
  response.setHeader("Cache-Control", "no-cache, must-revalidate");

  String ifNoneMatch = request.getHeader("If-None-Match");

  // The browser has the latest version
  if (quotedETag.equals(ifNoneMatch)) {
    response.setStatus(HttpServletResponse.SC_NOT_MODIFIED); // 304 Not Modified
  }
  // The browser needs the latest version
  else {

    String html = [LOAD YOUR HTML]

    response.setContentType("text/html");

    response.setCharacterEncoding("UTF-8");

    response.getWriter().append(html);

  }

}

You need a serverVersion somehow.  If using Google App Engine, you can do  System.getenv("GAE_VERSION");  otherwise, it's up to you how you get it and make it unique for each deploy.

On Friday, 13 February 2026 at 8:52:48 pm UTC+11 Jens wrote:

Yeah, using the gwt property is the easiest solution. I also use it. But be aware that you now have to update your webserver configuration to tell the browser to not cache the index.html anymore. Otherwise the embedded GWT code will be outdated if you deploy an updated version of your GWT app and all the hashes of *.cache.js files have changed.

-- J.

Craig Mitchell schrieb am Freitag, 13. Februar 2026 um 02:00:28 UTC+1:

Thanks Colin.  Dug around a little and figured out all I needed was:

<meta name="gwt:property" content="baseUrl=/dt/" />

("dt" is my GWT module short name)

Now everything works, including superdevmode.  Ie: No need for the gwtNoCacheJs.contains("superdevmode") check anymore.

I think my page does load a bit faster now (on subsequent times, not the first visit).  https://drift.team/ if anyone is curious what the end result root html source looks like.

On Friday, 13 February 2026 at 10:16:23 am UTC+11 Colin Alworth wrote:

I believe that https://github.com/gwtproject/gwt/blob/main/dev/core/src/com/google/gwt/core/ext/linker/impl/computeScriptBase.js is what you're going to want to read, or possibly replace on your classpath. Alternatively, subclass the CrossSiteIframeLinker to override getJsComputeScriptBase(LinkerContext) to provide your own file.

From that file:

/**
 * Determine our own script's URL by trying various things
 *
 * First - use the baseUrl meta tag if it exists
 * Second - look for a script tag with the src set to MODULE_NAME.nocache.js and
 *   if it's found, use it to determine the baseUrl
 * Third - if the page is not already loaded, try to use some document.write
 *   magic to install a temporary tag and use that to determine the baseUrl.
 *
 * This is included into the selection scripts
 * wherever COMPUTE_SCRIPT_BASE appears with underlines
 * on each side.
 */

The "Second" step is where you appear to be getting stuck - since there is no script tag with a src attr, the rest of the loading code doesn't know what to do. So, add a meta tag for baseUrl so the script knows where the other resources are loaded from.

Note that I haven't messed with this in years, and might have missed a point or two.

On Thursday, February 12, 2026 at 4:54:23 PM UTC-6 ma...@craig-mitchell.com wrote:

I tried to inject the non-dev nocache.js into my main index.html file.  Like this:

String gwtNoCacheJs = loadFileFromServlet("/dt/dt.nocache.js");

if (gwtNoCacheJs.contains("superdevmode")) {
  gwtNoCacheJs = "<script type='text/javascript' src='/dt/dt.nocache.js'></script>";
}
else {
  gwtNoCacheJs = "<script type='text/javascript'>\n" + gwtNoCacheJs + "\n</script>";
}

String html = loadFile("index.html").replace("XXX", gwtNoCacheJs);

However, it doesn't work, as nocache.js wants to load files from the same sub directory it's located in, and not the root directory.

Has anyone done this?  It probably isn't work the effort, as it'll only save one network call, but I was curious if it's possible.

--
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/9bdf6a9d-8c4a-43a2-bfef-a9fc865090f3n%40googlegroups.com.