GWT Code Server Jetty Mismatch

[Craig Mitchell]

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)

[Colin Alworth]

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.

[eliasb...@gmail.com]

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.