Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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
38 changes: 19 additions & 19 deletions build.gradle
Original file line number Diff line number Diff line change
@@ -1,32 +1,32 @@
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:2.0.2.RELEASE")
}
plugins {
id 'java'
id 'eclipse'
id 'idea'
id 'org.springframework.boot' version '3.3.13'
id 'io.spring.dependency-management' version '1.1.7'
}

apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'idea'
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'

bootJar {
baseName = 'gs-spring-boot'
version = '0.1.0'
archiveBaseName = 'gs-spring-boot'
archiveVersion = '0.1.0'
}

repositories {
mavenCentral()
}

sourceCompatibility = 1.8
targetCompatibility = 1.8
java {
sourceCompatibility = JavaVersion.VERSION_17
targetCompatibility = JavaVersion.VERSION_17
Comment on lines 17 to +20

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

📝 Info: source/targetCompatibility instead of a Java toolchain

Setting sourceCompatibility/targetCompatibility inside java { } only asserts the language level; the build still requires the invoking JDK to be 17+ and fails with a confusing 'invalid source release' / plugin-incompatibility error on an older JDK. Since this repo previously built on JDK 8, java { toolchain { languageVersion = JavaLanguageVersion.of(17) } } would make the requirement explicit and let Gradle provision/select the right JDK.

Open in Devin Review

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

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Deliberate for this PR — the migration plan specifies sourceCompatibility/targetCompatibility 1.8 → 17, and a toolchain would additionally make Gradle try to auto-provision/select a JDK, which changes build behaviour beyond the scope here. Happy to switch to java { toolchain { languageVersion = JavaLanguageVersion.of(17) } } as a follow-up if preferred.

}

dependencies {
compile("org.springframework.boot:spring-boot-starter-web")
testCompile("junit:junit")
implementation("org.springframework.boot:spring-boot-starter-web")
implementation("org.springframework.boot:spring-boot-starter-jdbc")
implementation("com.h2database:h2")
Comment on lines 23 to +26

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 dependency set does not fully match pom.xml (properties-migrator missing)

The PR states the Gradle dependency set now matches pom.xml, but pom.xml also declares org.springframework.boot:spring-boot-properties-migrator with runtime scope, which has no Gradle counterpart (runtimeOnly(...)). Given this is a Boot 2 → 3 migration where the migrator's property-rename warnings are most useful, the omission is likely unintentional (or the migrator should be dropped from pom.xml in the sibling PR for consistency).

Open in Devin Review

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

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: spring-boot-properties-migrator is being dropped from pom.xml in the sibling Maven PR as part of this migration, so adding a runtimeOnly counterpart here would immediately need reverting. Once that lands, both builds match.

testImplementation("org.springframework.boot:spring-boot-starter-test")
}

tasks.named('test') {
useJUnitPlatform()
}
2 changes: 1 addition & 1 deletion gradle/wrapper/gradle-wrapper.properties
Original file line number Diff line number Diff line change
Expand Up @@ -3,4 +3,4 @@ distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-4.6-bin.zip
distributionUrl=https\://services.gradle.org/distributions/gradle-8.14.5-bin.zip

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🔍 Wrapper JAR and scripts are still Gradle 2.13 while the distribution URL jumps to 8.x

gradle/wrapper/gradle-wrapper.jar reports versionNumber=2.13 (build-receipt inside the jar, built 2016) and gradlew/gradlew.bat are the matching legacy scripts — only distributionUrl was bumped. Normally the wrapper is regenerated via ./gradlew wrapper --gradle-version 8.14.5, which updates the jar, both scripts and the properties file together. A 2016 wrapper jar bootstrapping a Gradle 8 distribution on JDK 17 usually still works (the author reports ./gradlew tasks succeeded), so this isn't flagged as a bug, but it leaves the repo in an inconsistent state (no distributionSha256Sum support, old script logic, missing networkTimeout handling) and is worth regenerating as part of this migration.

Open in Devin Review

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

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 intentionally left out of this PR: the scope for this session is build.gradle plus gradle-wrapper.properties only, since sibling sessions are editing the repo in parallel and ./gradlew wrapper --gradle-version 8.14.5 would also rewrite gradlew, gradlew.bat and gradle-wrapper.jar. The legacy bootstrap does work (verified ./gradlew tasks and ./gradlew dependencies on JDK 17); regenerating the full wrapper is a good cleanup follow-up.

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 8.14.5 distribution must be verified to exist

If gradle-8.14.5-bin.zip is not a published distribution, every wrapper invocation fails at download time with an opaque error. Worth confirming against https://services.gradle.org/distributions/ (the author's verification log only shows ./gradlew tasks output, not which distribution was resolved).

Open in Devin Review

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

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Verified — the wrapper actually downloaded and ran that distribution in this session: ~/.gradle/wrapper/dists/gradle-8.14.5-bin was populated by ./gradlew tasks, and Gradle's own output references https://docs.gradle.org/8.14.5/.... 8.14.5 is the latest 8.x release (Boot 3.3 does not support Gradle 9).