Saturday, February 14, 2026

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.

Friday, February 13, 2026

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.

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

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/9e8f90ca-9e51-4c1e-9642-4e0cdadb2a79n%40googlegroups.com.

Thursday, February 12, 2026

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

I should point out, this is only useful if you have a single page app.  If you load different html pages, don't do this, as you'll be reloading the nocache.js for each page.

On Friday, 13 February 2026 at 12:00:28 pm UTC+11 Craig Mitchell wrote:
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/f935eef0-0bb9-4802-b6d0-31e73f8996b2n%40googlegroups.com.

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

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/a77a4ea3-c4ed-48b8-bd3e-c3877109fd6bn%40googlegroups.com.