feature: Maven build to Spring Boot 3.3.13 / Java 17 - #64
amitmanchella-cog wants to merge 1 commit into
Conversation
Co-Authored-By: Amit Manchella <amit.manchella@cognition.ai>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
| <groupId>org.springframework.boot</groupId> | ||
| <artifactId>spring-boot-starter-parent</artifactId> | ||
| <version>2.0.2.RELEASE</version> | ||
| <version>3.3.13</version> |
There was a problem hiding this comment.
🔴 Application startup fails because the built-in database no longer understands the app's table setup commands
Upgrading the framework parent (spring-boot-starter-parent 3.3.13 at pom.xml:14) pulls in a major new version of the embedded database whose stricter SQL rules reject the table-creation statements the app runs on every startup, so the app crashes on boot.
Impact: Running the packaged application aborts during startup with a SQL syntax error instead of serving requests.
Managed H2 version jumps from 1.4.x to 2.x, breaking legacy DDL in Application.run
Spring Boot 3.3.x manages com.h2database:h2 at 2.2.x, while Boot 2.0.2 managed 1.4.x. hello/Application.java:65-66 executes:
DROP TABLE customers IF EXISTS— the trailingIF EXISTSform was removed in H2 2.x (onlyDROP TABLE IF EXISTS customersis accepted in the default mode).CREATE TABLE customers(id SERIAL, ...)— theSERIAL/IDENTITYpseudo data types were removed in H2 2.x in favor ofBIGINT GENERATED BY DEFAULT AS IDENTITY.
Since Application implements CommandLineRunner, this runs at startup and will throw, aborting the boot process. Even though this PR is scoped to pom.xml, the dependency-managed H2 upgrade is what triggers the failure, so the DDL must be updated (or the H2 version pinned/compat mode set) in the same migration.
Prompt for agents
The parent bump to Spring Boot 3.3.13 changes the dependency-managed H2 version from 1.4.x to 2.2.x. The startup DDL in src/main/java/hello/Application.java (CommandLineRunner.run) uses two constructs that H2 2.x no longer accepts in its default mode: 'DROP TABLE customers IF EXISTS' (trailing IF EXISTS) and the 'SERIAL' column type. As a result the application will fail during startup with a SQL syntax error. Fix by modernizing the DDL (e.g. 'DROP TABLE IF EXISTS customers' and 'id BIGINT GENERATED BY DEFAULT AS IDENTITY'), or alternatively by configuring an H2 legacy compatibility mode / pinning the H2 version. Coordinate this with the sibling src/ migration PR so the migration lands consistently.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Confirmed: Application.run (src/main/java/hello/Application.java:66-67) uses DROP TABLE customers IF EXISTS and id SERIAL, both rejected by H2 2.2.x. The fix belongs in src/, which is explicitly out of scope for this PR — a sibling session owns the source migration (javax→jakarta plus this DDL). Not fixing here to avoid merge conflicts; flagged to the coordinator so the DDL lands with the source PR.
|
|
||
| <properties> | ||
| <java.version>1.8</java.version> | ||
| <java.version>17</java.version> |
There was a problem hiding this comment.
🔍 Gradle build left on Spring Boot 2.0.2 / Java 8
build.gradle still uses spring-boot-gradle-plugin:2.0.2.RELEASE with sourceCompatibility/targetCompatibility = 1.8 (and the removed compile/testCompile configurations). Until the sibling Gradle PR lands, the repository has two build systems targeting different Spring Boot majors and JDKs, so a Gradle build will produce a materially different artifact than the Maven build. Worth confirming the merge order of the sibling PRs.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Intentional: build.gradle is owned by a sibling PR in this parallel migration. All three (Maven, Gradle, src/) are meant to land together; the interim divergence is expected.
| <groupId>org.springframework.boot</groupId> | ||
| <artifactId>spring-boot-starter-parent</artifactId> | ||
| <version>2.0.2.RELEASE</version> | ||
| <version>3.3.13</version> |
There was a problem hiding this comment.
🔍 Packaging is pom, so sources are never compiled by this build
The project declares <packaging>pom</packaging> while carrying real sources under src/main/java. With pom packaging, maven-compiler-plugin and spring-boot-maven-plugin:repackage do not run, which means the successful dependency:resolve verification mentioned in the description does not exercise compilation at all — the Java 17 / Jakarta migration breakage in src/ will stay invisible to Maven even after the sibling PR. Pre-existing, but it undermines the confidence signal for this migration.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Correct and pre-existing — <packaging>pom</packaging> means dependency:resolve only validates dependency coordinates, not compilation. I described the check as a resolution check, not a build. Changing packaging to jar is a build-semantics change beyond this PR's stated scope; leaving it for the end-to-end verification session.
Summary
Maven-only slice of the Java 8 / Spring Boot 2.0.2 → Java 17 / Spring Boot 3.3.x migration.
pom.xmlis the sole file touched; sibling PRs coverbuild.gradleandsrc/.spring-boot-starter-parent:2.0.2.RELEASE→3.3.13(latest 3.3.x on Maven Central)java.version:1.8→17spring-boot-properties-migrator(transitional 1.x→2.x helper, obsolete)spring-boot-starter-web,spring-boot-starter-jdbc,com.h2database:h2, andspring-boot-maven-pluginare unchanged.Verified with
mvn -B -DskipTests dependency:resolve: resolves cleanly to Spring Boot 3.3.13 / Spring Framework 6.1.21 / Tomcat 10.1.42 / H2 2.2.224. Compilation ofsrc/is expected to fail until the siblingjavax.*→jakarta.*source PR lands.Link to Devin session: https://app.devin.ai/sessions/980045d1ddd5479ca97be91da06e129d
Requested by: @amitmanchella-cog
Devin Review