Quando Gradle 9, Docker 29 e Testcontainers si mettono la milza al court-bouillon : debugging di un build JHipster

Publié le 25 April 2026

Table des matières
tempo di lettura : 15 minutes

Hai già conosciuto quel momento in cui un semplice`./gradlew build`che lanci cento volte al giorno si blocca improvvisamente su un errore mai visto? Moltiplicalo per undici errori consecutivi, aggiungi una buona dose di incompatibilità Docker Engine 29, cospargi di Gradle 9 che fa scomparire le API che usavate da dieci anni. Ecco il diario di bordo completo.

Diagramma 1 — Migrazione Gradle 9 (catena di errori)

Obiettivo: mostrare la serie di incompatibilità.

👉 Chiaro, focalizzato su Gradle.
Failed to generate image: PlantUML preprocessing failed: [From <input> (line 4) ]

@startuml
left to right direction
title Migrazione Gradle 9
rectangle "1
^^^^^
 Syntax Error? (Assumed diagram type: class)

@startuml
left to right direction
title Migrazione Gradle 9
rectangle "1
reportsDir" as A
rectangle "2
mainClass" as B
rectangle "3\nsourceCompatibility" as C
rectangle "4
Groovy assert" as D

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

@enduml
Diagramma 2 — Plugin JHipster incompatibili

Obiettivo: isolare i plugin rotti.

👉 Visione pulita delle dipendenze.
Failed to generate image: PlantUML preprocessing failed: [From <input> (line 8) ]

@startuml
left to right direction
title Plugin da correggere
skinparam shadowing false
skinparam roundcorner 18

rectangle "1\nopenApiGenerate" as A #FFF3E0
rectangle "2
^^^^^
 Syntax Error? (Assumed diagram type: component)

@startuml
left to right direction
title Plugin da correggere
skinparam shadowing false
skinparam roundcorner 18

rectangle "1\nopenApiGenerate" as A #FFF3E0
rectangle "2
gitProperties
2.5.7" as B #FFF3E0
rectangle "3
Versioni
corrette" as C #E3F2FD
rectangle "4\nAssembla OK" as D #E8F5E9

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

@enduml
Diagramma 3 — Docker 29 / Testcontainers

Obiettivo: problema runtime.

👉 Storia chiara del runtime.
Failed to generate image: PlantUML preprocessing failed: [From <input> (line 10) ]

@startuml
left to right direction
title Docker 29 + Testcontainers

skinparam shadowing false
skinparam roundcorner 18
skinparam defaultFontSize 14

rectangle "1\nAssemblaggio OK" as A #E8F5E9
rectangle "2
^^^^^
 Syntax Error? (Assumed diagram type: component)

@startuml
left to right direction
title Docker 29 + Testcontainers

skinparam shadowing false
skinparam roundcorner 18
skinparam defaultFontSize 14

rectangle "1\nAssemblaggio OK" as A #E8F5E9
rectangle "2
Test di Cucumber fallito" as B #FFEBEE
rectangle "3
Testcontainers 1.32
rifiutato" as C #FFF3E0
rectangle "4
Upgrade
versioni" as D #E3F2FD
rectangle "5
Costruisci finale OK" as E #E8F5E9

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

@enduml
un altro modo di rappresentarselo
Failed to generate image: PlantUML preprocessing failed: [From <input> (line 17) ]

@startuml


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

title Roadmap di Stabilizzazione — Gradle 9 verso Build Finale
left to right direction

rectangle "�⚙️ Migrazione Gradle 9" as A #E3F2FD
rectangle "🧩 Plugin JHipster" as B #FFF3E0
rectangle "�🐳 Docker 29
^^^^^
 Syntax Error? (Assumed diagram type: component)

@startuml

!option handwritten true

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

title Roadmap di Stabilizzazione — Gradle 9 verso Build Finale
left to right direction

rectangle "�⚙️ Migrazione Gradle 9" as A #E3F2FD
rectangle "🧩 Plugin JHipster" as B #FFF3E0
rectangle "�🐳 Docker 29
Testcontainers" as C #FCE4EC
rectangle "### Integrazione Gradle
JBake può essere integrato nelle build Gradle utilizzando il plugin Gradle JBake o chiamando direttamente l'interfaccia a riga di comando JBake:

```kotlin
tasks.register<JavaExec>("bake") {
    mainClass.set("org.jbake.launcher.Main")
    classpath = configurations["jbake"]
    args = listOf(projectDir.absolutePath, "$buildDir/jbake")
}" as D #E8F5E9

note bottom of A
reportsDir
mainClass
sourceCompatibility
Groovy assert
end note

note bottom of B
openApiGenerate
gitProperties
versions alignées
end note

note bottom of C
tests Cucumber KO
image Docker rejetée
upgrade libs
end note

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

@enduml

La scena: un progetto JHipster, un build che non si carica più

Il progetto`edster`è un’applicazione JHipster generata nel 2024. Lo script di build della radice`build.gradle`è rimasto stabile per mesi. Poi si decide di passare alla versione :

Componente

Version cible

Gradle

9.4.1

Java

21.0.11-tem (Eclipse Temurin)

JHipster

8.x (framework)tech.jhipster:jhipster-framework:8.11.0)

Spring Boot

3.4.5

# Integrazione Gradle JBake può essere integrato nei build Gradle utilizzando il plugin Gradle JBake oppure richiamando direttamente la CLI JBake :

Il passaggio alla versione Java avviene tramite SDKMAN :

sdk use java 21.0.11-tem

Primo lancio:

$ ./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'

Non riusciamo nemmeno a partire dal caricamento dello script di build. Il problema è in`buildSrc/src/main/groovy/jhipster.cucumber-conventions.gradle`.

Errore 1 : la variabile fantasma `reportsDir

Lo script`jhipster.cucumber-conventions.gradle`contiene :

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"
    // ...
}

La variabile definita è`cucumberReportsDir`# JBake CLI Commands ` # Initialize a new JBake project jbake -i

Bake (generate) the site jbake -b

Bake and serve locally jbake -b -s

Bake and watch for changes jbake -b --reset

Specify source and destination jbake source_folder output_folder

Clear the output directory before baking jbake -b . output --reset `

  1. Quella utilizzata è`reportsDir`-- che non è definita da nessuna parte.

Correzione:`outputs.dir(cucumberReportsDir)`

Errore 2 : main = "…​" non esiste più in Gradle 9

Rilancio immediato :

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

Gradle 9 rimuove la proprietà`main`a favore di`mainClass`sui compiti`JavaExec`.

Correzione</think> :`mainClass = "org.junit.platform.console.ConsoleLauncher"`

Errore 3 : sourceCompatibility non è più una proprietà del progetto

Nuovo errore :

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

Lo script radice aveva :

sourceCompatibility=17
targetCompatibility=17

Gradle 9 rimuove queste proprietà a livello root. Devono vivere in un blocco`java`.

Correzione:

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

Errore 4 : l’asserzione Groovy con tre operandi

Lo script precedente conteneva :

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

In Groovy,"21" et "24"`sono delle strings truthy. L’espressione risolve in(…​ == "17") || true || true`, ciò che è sempre vero — ma la sintassi è non valida per l’asserzione rigorosa desiderata.

Correzione:

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

Errore 5 : la dipendenza implicita compileKotlin → `openApiGenerate

La build procede. Compilazione Kotlin riuscita. Poi :

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

Gradle 9 rifiuta le dipendenze implicite tra le attività. Poiché`compileKotlin`legge le fonti generate da`openApiGenerate`, è necessario dichiarare il collegamento.

Correzionein`build.gradle`:

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

Le afterEvaluate`è necessario perché`openApiGenerate`JBake riferimento (questo contenuto utilizza i modelli e le convenzioni di JBake): # Comandi CLI JBake `` # Initialize a new JBake project jbake -i

Bake (generate) the site jbake -b

Bake and serve locally jbake -b -s

Bake and watch for changes jbake -b --reset

Specify source and destination jbake source_folder output_folder

Clear the output directory before baking jbake -b . output --reset ` Traduci dal francese all’italiano. Preserva tutti gli span di codice tra backticks (…​) esattamente così — mai modificare il contenuto dei backticks, spaziatura o posizione. Questo testo può essere un frammento di una frase più ampia — traduci il frammento senza richiedere ulteriori contesto. Emetti solo il testo tradotto — nessuna spiegazione, nessun commento, nessuna introduzione, nessuna alternativa, nessuna opzione. è un’estensione (plugin OpenAPI Generator) e non è un’attività direttamente accessibile durante la fase di configurazione.

Errore 6 : generateGitProperties si interrompe su `FilterOutputStream.write()

La compilazione Java passa. Le risorse sono elaborate. Poi :

> Task :generateGitProperties FAILED

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

Il plugin`gradle-git-properties`versione 2.5.0 è incompatibile con Java 21 / Gradle 9. Un bug interno tenta di chiamare`write(int)`via Groovy su un flusso che l’ha chiuso

Correzionein`gradle.properties`:

gitPropertiesPluginVersion=2.5.7

Finalmente: Testcontainers entra in scena

Finora, era puro "debugging degli script di build". Ogni errore era un’incompatibilità Gradle 9 o Java 21 negli script di build. Dopo le sei correzioni sopra, il`./gradlew assemble`passa con successo.

ma`./gradlew build`esegue anche i test, e i test Cucumber utilizzano Testcontainers per avviare un PostgreSQL effimero.

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 è incapace di comunicare con Docker. Due strategie diverse (variabili d’ambiente + socket Unix) falliscono nello stesso errore.

Failed to generate image: PlantUML preprocessing failed: [From <input> (line 5) ]

@startuml
skinparam backgroundColor #FEFEFE
skinparam handwritten false

actor "Testcontainers
^^^^^
 Syntax Error? (Assumed diagram type: sequence)

@startuml
skinparam backgroundColor #FEFEFE
skinparam handwritten false

actor "Testcontainers
1.20.6" as TC
participant "docker-java\n3.4.1" as DJ
participant "Docker Engine
29.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

Fase 1: la pista docker-java

Primo riflesso: il client Docker Java utilizzato da Testcontainers invia la versione API`1.32`nel suo handshake HTTP, ma Docker Engine 29.4.1 richiede un minimo di`1.40`. Il problema è a livello del client, non del daemon.

Verifica della versione di docker-java risolta da 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, datato da Testcontainers 1.20.6. L’ultima versione pubblica di docker-java è 3.5.1. Proviamo a forzare l’aggiornamento della versione tramite`resolutionStrategy`nel blocco`configurations` de build.gradle(no output)

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

Riavvio della build. Stesso errore:`client version 1.32 is too old`.

Verifica della cache Gradle: i JAR sono stati effettivamente riscaricati, ma l’errore persiste. docker-java 3.5.1 invia sempre`1.32`. Questa versione quindi NON è sufficiente per Docker Engine 29.4.1.

Azione di purificazione: svuotare completamente la cache Gradle, solo per essere sicuri :

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

Riavvio completo dopo la pulizia. Stesso errore.

Fase 2: ricerca web e breadcrumb di GitHub

docker-java 3.5.1 è insufficiente. Non resta altro che cercare se qualcuno ha riscontrato questo problema esatto.

Ricerca mirata sulle issue testcontainers-java e 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

Primi risultati immediati :

Il breadcrumb è chiaro : Docker Engine 29.x ha innalzato la sua versione minima dell’API di`1.24`(difetto precedente) a`1.40`. Testcontainers 1.20.x utilizza docker-java 3.4.x che negozia la versione API inviando`1.32`. Il daemon rifiuta cortesemente ma fermemente.

Nell’issue #11491, un manutentore risponde:

(No output) Ciao, ho un progetto in esecuzione con la versione 2.0.3 su un runner GH con engine 29.1 e funziona. Potete tutti per favore controllare che non ci sia un conflitto di versione? Please, remember all modules were prefixed with testcontainers-. Così, a partire dalla versione 2.x siamo passati da`postgresql` to testcontainers-postgresql (No output)

Questa risposta contienedue informazioni critiche</think> (No output)

  1. Testcontainers 2.0.3+ risolve il problema

  2. I moduli sono statirinominati con il prefisso `testcontainers-

Fase 3: la trappola degli artefatti rinominati

Il rinominamento è brutale. In Testcontainers 2.x, nessun nome precedente funziona più sotto questo nome :

Vecchio nome (1.x)

Nuovo nome (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

invariato

Primo tentativo: applicare la BOM Testcontainers 2.0.5 e i nuovi nomi degli artefatti in`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.

Il BOM di testcontainers-bom non è sufficiente.Perché? Perché Spring Boot 3.4.5 espone il proprio BOM di gestione delle dipendenze (spring-boot-dependencies) chevincesul BOM di Testcontainers nella risoluzione trasitiva. Spring Boot corregge`testcontainers` à 1.20.6, e quindi tutti gli artifact che non sono esplicitamente nel BOM di Spring Boot (come i nuovi`testcontainers-*) risolvono verso i vecchi nomi`1.20.6-- che non esistono più in questa versione.

Ispezionando il`dependencies --configuration testRuntimeClasspath`, si trova:

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

Le →`indica la sostituzione : Testcontainers 2.0.5 è richiesto, ma Spring Boot forza`1.20.6.

Failed to generate image: PlantUML preprocessing failed: [From <input> (line 8) ]

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

left to right direction

component "build.gradle
^^^^^
 Syntax Error? (Assumed diagram type: class)

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

left to right direction

component "build.gradle
(consumatore)" as BG #E3F2FD {
    rectangle "richiesta
`testcontainers-bom:2.0.5" as REQ
    rectangle "richiesta
`testcontainers-postgresql" as REQ2
}

component "Maven Centrale" as MC #FFF3E0

component "Dichiarazioni" as DEC #E8F5E9 {
    rectangle "testcontainers-bom:2.0.5`
fissa 2.0.5" as BOM2
    rectangle "spring-boot-dependencies:3.4.5`\ncorregge 1.20.6" as BOM1
}

component "Risoluzione Gradle" as RES #FFEBEE {
    rectangle "Versione vincente\n`testcontainers:1.20.6" as WIN #EF9A9A
}

BG --> DEC : "analizza i BOM"
BOM2 --> RES : "propone 2.0.5"
BOM1 --> RES : "propone 1.20.6"
WIN -> MC : "scarica\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

Fase 4: forzare la risoluzione

La strategia diventa doppia:

  1. Forzare docker-java alla sua versione 3.7.1 (testato come compatibile con Docker Engine 29)

  2. Forzare Testcontainers core alla versione 2.0.5 aggirando il BOM di Spring Boot

Failed to generate image: PlantUML preprocessing failed: [From <input> (line 8) ]

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

left to right direction

component "build.gradle
^^^^^
 Syntax Error? (Assumed diagram type: class)

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

left to right direction

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

component "Conflitto risolto" as RESOLVED #E3F2FD {
    rectangle "docker-java\n`3.7.1` (forzato)" as DJ
    rectangle "testcontainers
`2.0.5` (forzato)" as TC #81C784
    rectangle "testcontainers-postgresql
`2.0.5" as TPG
    rectangle "testcontainers-jdbc\n`2.0.5" as TJ
    rectangle "testcontainers-junit-jupiter
`2.0.5" as TJJ
}

component "BOM Spring Boot\n(implicito, superato)" as BOM1 #FFEBEE

component "Maven Central" as MC #FFF3E0

BG --> RESOLVED : "BOM Testcontainers 2.0.5
passa direttamente"
RS -> DJ : "forza 3.7.1"
RS -> TC : "forza 2.0.5"
RESOLVED --> MC : "scarica i JAR
compatibili Docker 29"
BOM1 -[#gray,dashed]-> RESOLVED : "ignorato su 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

Correzione finalein`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`è l’unico modo per superare il BOM`spring-boot-dependencies`gestito dal plugin Spring Boot. Il test di uguaglianza su`details.requested.name == "testcontainers"`è volontariamente restrittivo: si impone solo il modulo core. I moduli`testcontainers-*`seguono la BOM di Testcontainers 2.0.5 che abbiamo dichiarato esplicitamente

Risultato finale

$ ./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 riescono finalmente a creare i loro container PostgreSQL tramite Docker Engine 29.4.1. L’errore di dominio finale (HTTP 500 sul test Cucumber) è un problema applicativo totalmente indipendente dallo script di build.

Tabella riepilogativa delle correzioni

(no output) File Problema Correzione

1

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

variabile`reportsDir`inexistente

outputs.dir(cucumberReportsDir)

2

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

`main`deprecato Gradle 9

mainClass

3

build.gradle

`sourceCompatibility`top-level vietato Gradle 9

blocco`java { sourceCompatibility = JavaVersion.VERSION_21 }`

4

build.gradle

Affermazione Groovy sintatticamente non valida

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

5

build.gradle

Dipendenza implicita`compileKotlin`→openApiGenerate

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

6

gradle.properties

gitPropertiesPluginVersion incompatible Java 21

2.5.7

7

Cache Gradle

docker-java 3.5.1 testato, risolto ma insufficiente

Purga + passaggio docker-java 3.7.1

8

build.gradle

Testcontainers 1.20.6 incompatibile con Docker Engine 29

Forzatura Testcontainers 2.0.5 + prefisso`testcontainers-*`+ resolutionStrategy vs Spring Boot BOM

Conclusione

Se il tuo build JHipster/Gradle si blocca dopo un aggiornamento alla versione di Gradle 9 + Docker Engine 29, gli errori si suddividono in due categorie :

Errori di script di build(le prime 6) : Gradle 9 rimuove proprietà e sintassi che funzionavano da anni`sourceCompatibility=, `main =, reportsDir). Sono migrazioni meccaniche una volta che si conosce la nuova API.

Errori di runtime Docker(le ultime 2) : Docker Engine 29.4.1 esclude i client API < 1.40. Testcontainers 1.20.6 (imposto da Spring Boot 3.4.5) utilizza docker-java 3.4.1 che invia la versione 1.32. Solo Testcontainers 2.0.5 + docker-java 3.7.1 risolvono il problema, con il rinominare gli artefatti e forzare la versione tramite`resolutionStrategy.eachDependency`come unico modo per aggirare il BOM implicito di Spring Boot.

Lo script di build Gradle alla radice del progetto è ora pulito.`./gradlew build`passa a Java 21, Gradle 9.4.1, Spring Boot 3.4.5 e Docker Engine 29.4.1.

Articoli correlati

HyperFrames-Gradle: Converti l'AsciiDoc in video MP4
31 May 2026
L'architettura « Plugin Indipendente + Radice Consumatore » : Perché i miei build Gradle si duplicano
14 May 2026
Il Knowledge Graph come motore di raccomandazione: come ho ucciso gli « articoli correlati » cronologici
12 May 2026
Cumulare Due Abbonamenti Ollama Pro sulla Stessa Macchina con Docker
08 May 2026