Quand Gradle 9, Docker 29 et Testcontainers se mettent la rate au court-bouillon : debugging d'un build JHipster

Δημοσιεύτηκε 25 April 2026

χρόνος ανάγνωσης : 15 minutes

Έχετε ήδη βιώσει αυτή τη στιγμή όπου ένα απλό`./gradlew build`που τρέχετε εκατόν φορές τη μέρα αρχίζει σ럽게 να πέσει σε σφάλμα που δεν είδατε ποτέ ? Πολλαπλασιάστε το με έντεκα επακολουθούμενα σφάλματα, προσθέστε μια καλή δοση ανυπαξαρμογής Docker Engine 29, σιρίσετε με Gradle 9 που κάνει να εξαφανιστούν API που χρησιμοποιούσαμε για δέκα χρόνια. Εδώ είναι το πλήρες δεfterολογιο.

Διάγραμμα 1 — Μετακόμιση Gradle 9 (αλλοιοσειρά σφαλμάτων)

Σκοπός: να δείξει τη σειρά ανεπαξεργαστών.

👉 Σαφής, εστιασμένο στο Gradle.
@startuml
left to right direction
title Μετάβαση σε Gradle 9
rectangle "1\nreportsDir" as A
rectangle "2\nmainClass" as B
rectangle "3\nsourceCompatibility" as C
rectangle "4\nGroovy assert" as D

A --> B
B --> C
C --> D

@enduml
Διάγραμμα 2 — Ανασύμφωνα plugins JHipster

Σκοπός: να απομονώσουμε τα κατεστραμμένα plugins

👉 Καθαρή όραση των εξαρτήσεων.
@startuml
left to right direction
title Plugins προς διόρθωση
skinparam shadowing false
skinparam roundcorner 18

rectangle "1\nopenApiGenerate" as A #FFF3E0
rectangle "2\ngitProperties\n2.5.7" as B #FFF3E0
rectangle "3\nΕκδόσεις\nδιορθωμένες" as C #E3F2FD
rectangle "4\nΣυναρμολόγηση OK" as D #E8F5E9

A --> B
B --> C
C --> D

@enduml
Διαγραμμα 3 — Docker 29 / Testcontainers

Στόχος: πρόβλημα χρόνου εκτέλεσης.

👉 Σαφής історία του runtime.
@startuml
left to right direction
title Docker 29 + Testcontainers

skinparam shadowing false
skinparam roundcorner 18
skinparam defaultFontSize 14

rectangle "1\nΣυναρμολόγηση OK" as A #E8F5E9
rectangle "2\nTests Cucumber ΑΠΟΤΥΧΙΑ" as B #FFEBEE
rectangle "3\nTestcontainers 1.32\nαπορρίφθηκε" as C #FFF3E0
rectangle "4\nΑναβάθμιση\nεκδόσεων" as D #E3F2FD
rectangle "5\nΤελικό Build OK" as E #E8F5E9

A --> B
B --> C
C --> D
D --> E

@enduml
ένας άλλος τρόπος να το apeικονίσεις
@startuml

!option handwritten true

skinparam backgroundColor #FEFEFE
skinparam shadowing false
skinparam defaultFontName Inter
skinparam defaultFontSize 14
skinparam ArrowThickness 2
skinparam RoundCorner 18

title Οδικός Χάρτης Σταθεροποίησης — Από Gradle 9 σε Τελικό Build
left to right direction

rectangle "⚙️ Μετάβαση σε Gradle 9" as A #E3F2FD
rectangle "🧩 Plugins JHipster" as B #FFF3E0
rectangle "🐳 Docker 29\nTestcontainers" as C #FCE4EC
rectangle "✅ Σταθερό Build" as D #E8F5E9

note bottom of A
reportsDir
mainClass
sourceCompatibility
Groovy assert
end note

note bottom of B
openApiGenerate
gitProperties
ευθυγραμμισμένες εκδόσεις
end note

note bottom of C
έλεγχοι Cucumber KO
εικόνα Docker απορρίφθηκε
αναβάθμιση βιβλιοθηκών
end note

A -[#42A5F5]-> B : corrections build.gradle
B -[#FB8C00]-> C : assemble OK
C -[#E53935]-> D : tests réparés

@enduml

Η σκηνή: ένα έργο JHipster, ένα build που δεν φορτώνει πια

Το έργο`edster`είναι μια εφαρμογή JHipster που δημιουργήθηκε το 2024. Ο βασικός build script`build.gradle`έμεινε σταθερός για μήνες. Στη συνέχεια αποφασίζουμε να αναβαθμίσουμε την έκδοση:

Συστατικό Στοχευμένη έκδοση

Gradle

9.4.1

Java

21.0.11-tem (Eclipse Temurin)

JHipster

8.x (πλαίσιο`tech.jhipster:jhipster-framework:8.11.0`)

Spring Boot

3.4.5

Κοτλιν

2.3.0

Docker Engine

29.4.1 (API 1.54)

Η αλλαγή έκδοσης Java γίνεται μέσω του SDKMAN :

sdk use java 21.0.11-tem

Πρώτη εκκίνηση:

$ ./gradlew build --no-daemon

FAILURE: Build failed with an exception.

* Where:
Build file '/home/.../edster/build.gradle' line: 18

* What went wrong:
An exception occurred applying plugin request [id: 'jhipster.cucumber-conventions']
> Failed to apply plugin 'jhipster.cucumber-conventions'.
   > Could not create task ':cucumberTest'.
      > Could not create task ':consoleLauncherTest'.
         > Could not set unknown property 'reportsDir' for task ':consoleLauncherTest'

Ακόμη δεν φτάνουμε από το φόρτωση του build script. Το πρόβλημα είναι στον`buildSrc/src/main/groovy/jhipster.cucumber-conventions.gradle`.

Σφάλμα 1: η φαντασματική μεταβλητή `reportsDir

Το σενάριο`jhipster.cucumber-conventions.gradle`περιέχει :

tasks.register('consoleLauncherTest', JavaExec) {
    dependsOn(testClasses)
    String cucumberReportsDir = file("$buildDir/reports/tests")
    outputs.dir(reportsDir)           // <-- reportsDir n'existe PAS
    classpath = sourceSets["test"].runtimeClasspath
    main = "org.junit.platform.console.ConsoleLauncher"
    // ...
}

Η ορισμένη μεταβλητή είναι`cucumberReportsDir`. Η που χρησιμοποιείται είναι`reportsDir`-- που δεν ορίζεται πουθενά.

Διορθωση : outputs.dir(cucumberReportsDir)

Σφάλμα 2: main = "…​" δεν υπάρχει πλέον στο Gradle 9

Αμέσως επανεκκίνηση:

Could not set unknown property 'main' for task ':consoleLauncherTest' of type org.gradle.api.tasks.JavaExec.

Το Gradle 9 αφαιρεί την ιδιότητα`main`στο όφελος του`mainClass`στις εργασίες`JavaExec`.

Διόρθωση:`mainClass = "org.junit.platform.console.ConsoleLauncher"`

Σφάλμα 3 : sourceCompatibility δεν είναι πια μια ιδιότητα του έργου

Νέο σφάλμα :

Could not set unknown property 'sourceCompatibility' for root project 'edster' of type org.gradle.api.Project.

Το ριζικό script είχε :

sourceCompatibility=17
targetCompatibility=17

Το Gradle 9 διαγράφει αυτές τις ιδιότητες στο επίπεδο ρίζας. Πρέπει να ζουν εντός ενός μπλοκ.java.

Διόρθωση:

java {
    sourceCompatibility = JavaVersion.VERSION_21
    targetCompatibility = JavaVersion.VERSION_21
}

Σφάλμα 4: η Groovy assertion με τρείς οπεράνδες

Το παλιό σενάριο περιείχε:

assert System.properties["java.specification.version"] == "17" || "21" || "24"

Στην Groovy,"21" et "24"`είναι strings truthy. Η έκφραση λύνει σε(…​ == "17") || true || true`, ó,τι είναι πάντα αληθές — αλλά η σύνταξη είναι μη έγκυρη για την επιθυμητή αυστηρή διδασκαλία.

Διορθωση:

assert System.properties["java.specification.version"] in ["17", "21", "23", "24"]

Σφάλμα 5 : η απόρρητη εξάρτηση compileKotlin → `openApiGenerate

Η build προχωρά. Η Κόμπιλαις Kotlin ήταν επιτυχής. Στη συνέχεια :

Task ':compileKotlin' uses this output of task ':openApiGenerate'
without declaring an explicit or implicit dependency.

Το Gradle 9 απορρίπτει τις υπόνυμες εξαρτήσεις μεταξύ των εργασιών. Επειδή`compileKotlin`διαβάζει τις γενημένες πηγές από`openApiGenerate`, πρέπει να δηλώσουμε τον σύνδεσμο.

Διόρθωσησε`build.gradle`:

afterEvaluate {
    tasks.named("compileKotlin").configure {
        dependsOn(tasks.named("openApiGenerate"))
    }
}

Le `afterEvaluate`είναι απαραίτητο επειδή`openApiGenerate`είναι μια επέκταση (plugin OpenAPI Generator) και όχι μια εργασία που είναι άμεσα προσβάσιμη κατά τη φάση της διαμόρφωσης.

Σφάλμα 6 : generateGitProperties σπάει στο `FilterOutputStream.write()

Η μεταγλώττιση του Java πέτυχε. Οι πόροι είναι επεξεργασμένοι. Στη συνέχεια:

> Task :generateGitProperties FAILED

No signature of method: java.io.FilterOutputStream.write() is applicable for argument types: (Integer) values: [103]

Το plugin`gradle-git-properties`Η έκδοση 2.5.0 δεν είναι συμβατή με Java 21 / Gradle 9. Έσωτερικό σφάλμα προσπαθεί να καλέσει`write(int)`μέσω Groovy σε μια ροή που την έκλεισε.

Διόρθωσησε`gradle.properties`:

gitPropertiesPluginVersion=2.5.7

Τελικά: Το Testcontainers εμφανίζεται στη σκηνή

Μέχρι τώρα, ήταν καθαρό "build script debugging". Κάθε σφάλμα ήταν μια ανυπακούστι Gradle 9 ή Java 21 στα scripts build. Μετά από τις έξι διόρθωσης παραπάνω, το`./gradlew assemble`περνάει με επιτυχία.

Αλλά`./gradlew build`εκτελεί επίσης τα τεστ, και τα τεστ Cucumber χρησιμοποιούν Testcontainers για να εκκινήσουν ένα εφημερές PostgreSQL.

Could not find a valid Docker environment.

EnvironmentAndSystemPropertyClientProviderStrategy: failed with exception BadRequestException
(Status 400: {"message":"client version 1.32 is too old. Minimum supported API version is 1.40"}
UnixSocketClientProviderStrategy: failed with exception BadRequestException
(Status 400: {"message":"client version 1.32 is too old. Minimum supported API version is 1.40"}

Το Testcontainers δεν είναι σε θέση να επικοινωνήσει με το Docker. Δύο διαφορετικές στρατηγικές (μεταβλητές περιβάλλοντος + Unix socket) αποτυγχάνουν με το ίδιο σφάλμα.

@startuml
skinparam backgroundColor #FEFEFE
skinparam handwritten false

actor "Testcontainers\n1.20.6" as TC
participant "docker-java\n3.4.1" as DJ
participant "Docker Engine\n29.4.1" as DE

TC -> DJ : new DockerClient()
DJ -> DE : GET /_ping\nUser-Agent: docker-java/3.4.1\nAPI-Version: 1.32
DE --> DJ : HTTP 400 Bad Request\nclient version 1.32 is too old.\nMinimum supported API version is 1.40
DJ --> TC : BadRequestException
TC --> TC : Could not find a valid\nDocker environment

note right of DE
  Docker Engine 29.x impose
  API minimum = 1.40
  (défaut ancien : 1.24)
end note

note left of DJ
  docker-java 3.4.1 envoie
  hardcoded API version 1.32
  dans l'en-tête HTTP
end note

@enduml

Phase 1 : ο δρόμος docker-java

Πρώτο αντανακλαστικό: ο πελάτης Docker Java που χρησιμοποιείται από το Testcontainers στέλνει την έκδοση API`1.32`στο handshake HTTP, αλλά το Docker Engine 29.4.1 απαιτεί ένα ελάχιστο του`1.40`. Το πρόβλημα είναι στον πελάτη, όχι στον daemon.

Έλεγχος της έκδοσης του docker-java που έχει επιλυθεί από το Testcontainers 1.20.6 :

$ ./gradlew dependencies --configuration testRuntimeClasspath | grep docker-java

+--- com.github.docker-java:docker-java-api:3.4.1
+--- com.github.docker-java:docker-java-transport:3.4.1

docker-java 3.4.1, που ημερολογείται από το Testcontainers 1.20.6. Η τελευταία δημόσια έκδοση του docker-java είναι 3.5.1. Ας προσπαθούμε να αναγκάσουμε την αναβάθμιση έκδοσης via`resolutionStrategy`στο μπλοκ`configurations` de build.gradle</think>

configurations {
    all {
        resolutionStrategy.eachDependency { details ->
            if (details.requested.group == "com.github.docker-java"
                && details.requested.name.startsWith("docker-java")) {
                details.useVersion("3.5.1")
            }
        }
    }
}

Επαναφορά του build. Το ίδιο σφάλμα:`client version 1.32 is too old`.

Έλεγχος του cache του Gradle: τα JARs έχουν ξανα-βεβαίως ληφθεί, αλλά το σφάλμα παραμένει. το docker-java 3.5.1 συνεχίζει να στέλνει`1.32`. Αυτή η έκδοση δεν είναι άρα επαρκής για το Docker Engine 29.4.1.

Πράξη καθαρισμού: διακαθαρίστε πλήρως το cache του Gradle, για να είστε σίγουροι :

rm -rf ~/.gradle/caches
rm -rf /path/to/project/.gradle

Πλήρης επανεκκίνηση μετά καθαρισμού. Το ίδιο λάθος.

Φάση 2: έρευνα διαδικτύου και διαδρομή Αριάδνης GitHub

docker-java 3.5.1 είναι ανεπαρκές. Μόνο να ψάξουμε αν κάποιος αντιμετώπισε αυτό το ακριβές πρόβλημα.

Στοχευμένη αναζήτηση στα ζητήματα testcontainers-java και docker-java:

site:github.com/testcontainers "client version 1.32 is too old"
site:github.com/docker-java "client version 1.32" Docker Engine 29

Αμέσα πρώτα αποτελέσματα:

Το νήμα της Αριάδνης είναι σαφές : Ο Docker Engine 29.x έχει αυξήσει την ελάχιστη έκδοση του API του σε`1.24`(παλιό λάθος) σε`1.40`. Testcontainers 1.20.x χρησιμοποιεί το docker-java 3.4.x το οποίο διαπραγματεύεται την έκδοση API στέλνοντας`1.32`. Ο δαίμονας αρνείται ευγενικά αλλά στερεά.

Στο issue #11491, ένας συντήρης απαντά :

_ Γεια, έχω ένα έργο που τρέχει με έκδοση 2.0.3 σε έναν εκτέλεστή GH με μηχανή 29.1 και λειτουργεί. Μπορείτε όλοι παρακαλώ να ελέγξετε ότι δεν υπάρχει σύγκρουση έκδοσης; Παρακαλώ, θυμηθείτε ότι όλα τα modules είχαν πρόθεμα`testcontainers-. Έτσι, από την έκδοση 2.x, περάσαμε από`postgresql to testcontainers-postgresql _

Αυτή η απάντηση περιέχειδύο κρίσιμες πληροφορίες :

  1. Testcontainers 2.0.3+ λύει το πρόβλημα

  2. Τα modules έχουν γίνειτονομασμένοι με το πρόθεμα `testcontainers-

Φάση 3: η παγίδα των μετονομασμένων artifacts

Η μετονομασία είναι βίαιη. Στον Testcontainers 2.x, κανένα από τα παλαιά ονόματα δεν λειτουργεί πλέον με αυτό το όνομα :

Παλαιό όνομα (1.x) Νέο όνομα (2.x)

org.testcontainers:postgresql

org.testcontainers:testcontainers-postgresql

org.testcontainers:jdbc

org.testcontainers:testcontainers-jdbc

org.testcontainers:junit-jupiter

org.testcontainers:testcontainers-junit-jupiter

org.testcontainers:testcontainers

αμετάβλητο

Πρώτη προσπάθεια: εφαρμόστε τη BOM Testcontainers 2.0.5 και τα νέα ονόματα artifacts σε`build.gradle`.

dependencies {
    testImplementation platform("org.testcontainers:testcontainers-bom:2.0.5")
    testImplementation "org.testcontainers:testcontainers-postgresql"
    testImplementation "org.testcontainers:testcontainers-jdbc"
    testImplementation "org.testcontainers:testcontainers-junit-jupiter"
    testImplementation "org.testcontainers:testcontainers"
}

./gradlew build

FAILURE: Could not find org.testcontainers:jdbc:2.0.5.
Could not find org.testcontainers:junit-jupiter:2.0.5.

Το BOM του testcontainers-bom δεν είναι αρκετό.Γιατί; επειδή Spring Boot 3.4.5 εκθέτει το δικό του BOM διαχείρισης εξαρτήσεων (spring-boot-dependencies) ο οποίοςνικάστο BOM του Testcontainers στη διάσυνδεδεμένη επίλυση. Spring Boot διορθώνει`testcontainers` à 1.20.6, και άρα όλα τα artifacts που δεν είναι ρητά στο BOM του Spring Boot (όπως τα νέα`testcontainers-*) λύνουν προς τα παλαιά ονόματα`1.20.6-- που δεν υπάρχουν πια σε αυτήν την έκδοση.

Επιθεωρώντας το`dependencies --configuration testRuntimeClasspath`, βρίσκεται :

+--- org.testcontainers:testcontainers -> 1.20.6 (*)
|    \--- org.testcontainers:testcontainers:2.0.5 -> 1.20.6

Le →`δεικνύει την αντικατάσταση : Testcontainers 2.0.5 είναι απαιτούμενο, αλλά το Spring Boot αναγκάζει`1.20.6.

@startuml
skinparam backgroundColor #FEFEFE
skinparam handwritten false
skinparam componentStyle rectangle

left to right direction

component "build.gradle\n(consommateur)" as BG #E3F2FD {
    rectangle "demande\n`testcontainers-bom:2.0.5`" as REQ
    rectangle "demande\n`testcontainers-postgresql`" as REQ2
}

component "Maven Central" as MC #FFF3E0

component "Déclarations" as DEC #E8F5E9 {
    rectangle "`testcontainers-bom:2.0.5`\nfixe 2.0.5" as BOM2
    rectangle "`spring-boot-dependencies:3.4.5`\nfixe 1.20.6" as BOM1
}

component "Résolution Gradle" as RES #FFEBEE {
    rectangle "Version gagnante\n`testcontainers:1.20.6`" as WIN #EF9A9A
}

BG --> DEC : "analyse les BOMs"
BOM2 --> RES : "propose 2.0.5"
BOM1 --> RES : "propose 1.20.6"
WIN -> MC : "télécharge\ntestcontainers:1.20.6"

note bottom of WIN
  Spring Boot BOM prime car
  le plugin spring-boot applique
  ses dépendances de gestion
  après la résolution du consommateur
end note

@enduml

Φάση 4 : προβάλουμε την λύση

Η στρατηγική γίνεται διπλή:

  1. Αναγκαίωσε το docker-java στην έκδοση 3.7.1 (ελεγμένο ότι είναι συμβατό με το Docker Engine 29)

  2. Αναγκάστε το Testcontainers core στην έκδοση 2.0.5, παρακάμπτοντας το BOM του Spring Boot

@startuml
skinparam backgroundColor #FEFEFE
skinparam handwritten false
skinparam componentStyle rectangle

left to right direction

component "build.gradle\n(avec resolutionStrategy)" as BG #E8F5E9 {
    rectangle "BOM Testcontainers\n`2.0.5`" as BOM2
    rectangle "`resolutionStrategy\n.eachDependency`" as RS #66BB6A
}

component "Conflit résolu" as RESOLVED #E3F2FD {
    rectangle "docker-java\n`3.7.1` (forcé)" as DJ
    rectangle "testcontainers\n`2.0.5` (forcé)" as TC #81C784
    rectangle "testcontainers-postgresql\n`2.0.5`" as TPG
    rectangle "testcontainers-jdbc\n`2.0.5`" as TJ
    rectangle "testcontainers-junit-jupiter\n`2.0.5`" as TJJ
}

component "BOM Spring Boot\n(implicite, outrepassé)" as BOM1 #FFEBEE

component "Maven Central" as MC #FFF3E0

BG --> RESOLVED : "BOM Testcontainers 2.0.5\npasse directement"
RS -> DJ : "force 3.7.1"
RS -> TC : "force 2.0.5"
RESOLVED --> MC : "télécharge les JARs\ncompatibles Docker 29"
BOM1 -[#gray,dashed]-> RESOLVED : "ignoré sur testcontainers\net docker-java"

note bottom of RS
  Le `eachDependency` intercepte
  la résolution Gradle AVANT
  que le BOM Spring Boot ne gagne.
  C'est une intervention chirurgicale.
end note

@enduml

Τελική διόρθωσημέσα`build.gradle`:

configurations {
    all {
        resolutionStrategy.eachDependency { details ->
            if (details.requested.group == "com.github.docker-java"
                && details.requested.name.startsWith("docker-java")) {
                details.useVersion("3.7.1")
            }
            if (details.requested.group == "org.testcontainers"
                && details.requested.name == "testcontainers") {
                details.useVersion("2.0.5")
            }
        }
    }
}

dependencies {
    testImplementation platform("org.testcontainers:testcontainers-bom:2.0.5")
    testImplementation "org.testcontainers:testcontainers-jdbc"
    testImplementation "org.testcontainers:testcontainers-junit-jupiter"
    testImplementation "org.testcontainers:testcontainers-postgresql"
    testImplementation "org.testcontainers:testcontainers"
    // ... autres dépendances Spring Boot
}

Le `resolutionStrategy.eachDependency`είναι ο μοναδικός τρόπος να παρακάμπτει το BOM`spring-boot-dependencies`διαχειρίζεται από το πρόσθετο Spring Boot. Ο έλεγχος ισότητας σε`details.requested.name == "testcontainers"`Είναι intentional restrictive: αναγκάζουμε μόνο τον πυρήνα του module. Τα modules`testcontainers-*`ακολουθούν το BOM του Testcontainers 2.0.5 που δηλώσαμε ρητά.

Τελικό αποτέλεσμα

$ ./gradlew build --no-daemon

> Task :consoleLauncherTest
[2 containers found]
[2 containers started]
[2 containers successful]

BUILD SUCCESSFUL in 1m 16s

Το Testcontainers 2.0.5 + το docker-java 3.7.1 καταφέρνουν τελικά να δημιουργήσουν τα containers PostgreSQL τους vía Docker Engine 29.4.1. Η τελική εμπορική σφάλμα (HTTP 500 στον τεστ Cucumber) είναι ένα εφαρμογικό πρόβλημα που είναι τελείως ανεξάρτητο από το script κατασκευής.

Πίνακας σύνοψης διόρθωσης

# Αρχείο Πρόβλημα Διόρθωση

1

buildSrc/src/main/groovy/jhipster.cucumber-conventions.gradle

Μεταβλητή`reportsDir`υφιστάμενη

outputs.dir(cucumberReportsDir)

2

buildSrc/src/main/groovy/jhipster.cucumber-conventions.gradle

`main`παρωχημένο Gradle 9

mainClass

3

build.gradle

`sourceCompatibility`απαγορεύεται top-level Gradle 9

μπλοκ`java { sourceCompatibility = JavaVersion.VERSION_21 }`

4

build.gradle

Η Groovy_assertion είναι σύνταξης μη έγκυρη

assert …​ in ["17", "21", "23", "24"]

5

build.gradle

εσυμπεριλημένη εξάρτηση`compileKotlin`→openApiGenerate

afterEvaluate { tasks.named("compileKotlin").dependsOn("openApiGenerate") }

6

gradle.properties

`gitPropertiesPluginVersion`ανεσυμβατό Java 21

2.5.7

7

αποθήκη Gradle

docker-java 3.5.1 δοκιμάστηκε, λύθηκε αλλά ανεπαρκές

Καθαρισμός + πάροδος docker-java 3.7.1

8

build.gradle

Testcontainers 1.20.6 μη συμβατό με Docker Engine 29

Απαίτηση Testcontainers 2.0.5 + πρόθεμα`testcontainers-*`+ resolutionStrategy vs Spring Boot BOM

Συμπέρασμα

Εάν η δημιουργία JHipster/Gradle σας αποτύχει μετά από μια αναβάθμιση Gradle 9 + Docker Engine 29, τα σφάλματα διαχωρίζονται σε δύο κατηγορίες:

Σφάλματα σε build script(τα 6 πρώτα) : Το Gradle 9 διαγράφει ιδιότητες και συντακτικές που δούλευαν για χρόνια (sourceCompatibility=, main =, reportsDir). Οι μετακινήσεις είναι μηχανικές ότανγνωρίζουμε την νέα API.

Σφάλματα χρόνου εκτέλεσης Docker(οι 2 τελευταίες): Docker Engine 29.4.1 απομακρύνει τους πελάτες API < 1.40. Testcontainers 1.20.6 (υποχρεωτικό από το Spring Boot 3.4.5) χρησιμοποιεί το docker-java 3.4.1 που στέλνει 1.32. Μόνο το Testcontainers 2.0.5 + docker-java 3.7.1 λύνει το πρόβλημα, με τη μετονομασία των artifacts και το ενσarcaσμα έκδοσης διά`resolutionStrategy.eachDependency`ο μοναδικός τρόπος για να αποφύγετε το εμνενό BOM του Spring Boot.

Το script Gradle στη ρίζα του έργου είναι τώρα καθαρό.`./gradlew build`τρέχει στο Java 21, Gradle 9.4.1, Spring Boot 3.4.5 και Docker Engine 29.4.1.

Σχετικά άρθρα

HyperFrames-Gradle : Μετατροπή του AsciiDoc σε Βίντεο MP4
31 May 2026
Audit de ma Consommation LLM : SQLite, OpenCode, Ollama Cloud, et Pourquoi Mon Abonnement Pro Éclate le Marché Mondial
18 May 2026
Η Αρχιτεκτονική «Plugin Indépendant + Racine Consommateur»: Γιατί τα Gradle Builds μου Διπλασιάζονται
14 May 2026
Le Knowledge Graph comme moteur de recommandation : comment j'ai tué les « articles connexes » chronologiques
12 May 2026