Skip to content

feature: Maven build to Spring Boot 3.3.13 / Java 17 #64

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
amitmanchella-cog wants to merge 1 commit into
base: master
Choose a base branch
from
Open

feature: Maven build to Spring Boot 3.3.13 / Java 17 #64

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 2 additions & 7 deletions pom.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,15 +11,10 @@
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.2.RELEASE</version>
<version>3.3.13</version>

@devin-ai-integration devin-ai-integration Bot Aug 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 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 trailing IF EXISTS form was removed in H2 2.x (only DROP TABLE IF EXISTS customers is accepted in the default mode).
  • CREATE TABLE customers(id SERIAL, ...) — the SERIAL/IDENTITY pseudo data types were removed in H2 2.x in favor of BIGINT 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.
Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

@devin-ai-integration devin-ai-integration Bot Aug 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@devin-ai-integration devin-ai-integration Bot Aug 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 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.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

@devin-ai-integration devin-ai-integration Bot Aug 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

</parent>

<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-properties-migrator</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
Expand All @@ -35,7 +30,7 @@
</dependencies>

<properties>
<java.version>1.8</java.version>
<java.version>17</java.version>

@devin-ai-integration devin-ai-integration Bot Aug 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 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.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

@devin-ai-integration devin-ai-integration Bot Aug 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

</properties>


Expand Down