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`جو آپ دن میں سو بار چلاتے ہیں، وہ نئی غلطی پر вдруг کراش ہو جاتا ہے۔ اسے گیارہ متوالی غلطیوں سے ضرب کریں، ڈاکر انجن 29 کی نامُوافقیت کی ایک مناسب مقدار شامل کریں، اور گریڈل 9 سے سیلک کرنے پر وہ APIS مٹ جاتی ہیں جن کو آپ پچھلے دس سال سے استعمال کر رہے ہیں۔ یہ مکمل لاگ بک ہے۔

ڈائاگرام 1 — Gradle 9 کی مایگریشن (غلطیوں کی زنجیرہ)

هدف : ناتوافقات کی سیریس دکھانا۔

👉 واضح، Gradle پر متمرکز
@startuml
left to right direction
title Migration 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 — JHipster پلاگائن نا‑مطابق

هدف : ٹوٹے پلاگ ان کو الگ کرنا۔

👉 مُعتمدگی کی واضح نظر.
@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\nVersions\nدرست کیے گئے" as C #E3F2FD
rectangle "4\nAssemble OK" as D #E8F5E9

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

@enduml
ڈائگرام 3 — Docker 29 / Testcontainers

هدف: رن-ٹائم مسلکہ

👉 رونٹائم کی واضح تاریخ
@startuml
left to right direction
title Docker 29 + Testcontainers

skinparam shadowing false
skinparam roundcorner 18
skinparam defaultFontSize 14

rectangle "1\nAssemble OK" as A #E8F5E9
rectangle "2\nTests Cucumber FAIL" as B #FFEBEE
rectangle "3\nTestcontainers 1.32\nمسترد" as C #FFF3E0
rectangle "4\nUpgrade\nورژنز" as D #E3F2FD
rectangle "5\nBuild final OK" as E #E8F5E9

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

@enduml
خود کو اسے تصور کرنے کا ایک دیگر طریقہ
@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 سے فائنل بلڈ تک
left to right direction

rectangle "⚙️ Gradle 9 کی طرف نقل مکانی (Migration)" as A #E3F2FD
rectangle "🧩 JHipster پلگ انز" as B #FFF3E0
rectangle "🐳 Docker 29\nTestcontainers" as C #FCE4EC
rectangle "✅ مستحکم بلڈ (Build Stable)" 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 ٹیسٹ ناکام
ڈاکر امیج مسترد
لائبریریز کی اپ گریڈیشن
end note

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

@enduml

منظر: ایک JHipster پروجیکٹ، ایک بیلڈ جو اب لاڈ نہیں ہو رہا

پروجیکٹ`edster`یہ 2024 میں جنریٹ کردہ JHipster ایپلیکیشن ہے۔ جڑو بنڈ سکرپٹ`build.gradle`یہ ماہوں تک مستقر رہا۔ پھر ہم نئی ورژن میں اپ گریٹ کرنے کا فیصلہ کرتے ہیں :

حصہ قصد شدہ ورژن

گریڈل

9.4.1

جاوا

21.0.11-tem (Eclipse Temurin)

JHipster

8.x (فریم ورک`tech.jhipster:jhipster-framework:8.11.0`)

Spring Boot

3.4.5

کاتلن

2.3.0

ڈاکر انجن

29.4.1 (API 1.54)

جاوے کی ورژن تبدیلی 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'

ہم بیلڈ اسکرپٹ کے لوڈ ہونے سے بھی نہیں اٹھ سکتے۔ مسئلہ یہ ہے کہ`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.

رُوٹ سکرپٹ میں تھا:

sourceCompatibility=17
targetCompatibility=17

گریڈل 9 انخصوصیات جڑ کی سطح پر حذف کرتا ہے۔ انخصوصیات ایک بلوک میں رہنا چاہیے`java`.

اصلاح:

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

غلطی 4 : Groovy کی تین آپیریینڈز والی تصدیق

پرانا سکرپٹ شامل تھا :

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

گراووی میں،"21" et "24"`سچے سٹرنگز ہیں. Expression حل ہوتا ہے میں(…​ == "17") || true || true`, جو ہمیشہ سچ ہے — لیکن سینٹکس غلط ہے مطلوب سخت استعیان کے لیے

صحیحی(empty)

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

غلطی 5 : ضمنی انحصار compileKotlin → `openApiGenerate

билڈ پیشروج ہو رہا ہے۔ کاتلن کامپائلیشن کامیاب ہو گئی۔ پھر :

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`یہ OpenAPI Generator پلاگین ایک ایکسٹینشن ہے اور سیٹ اپ کے مرحلے میں مستقیم قابل رسائی ہونے والا کام نہیں ہے۔

غلطی 6 : generateGitProperties ٹوٹ جاتا ہے FilterOutputStream.write() پر

جاوے کی کامپائلیشن کامیاب ہو جاتی ہے۔ وسائل پر عمل کیا جاتا ہے۔ بعد میں :

> Task :generateGitProperties FAILED

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

پلاگ ان`gradle-git-properties`ورژن 2.5.0 Java 21 / گریڈل 9 کے ساتھ متوافق نہیں ہے۔ اندرونی بگ کال کرنے کی کوشش کر رہا ہے۔`write(int)`Groovy کے ذریعے ایک سٹریم جس نے اسے بند کر دیا

تصحیحمیں`gradle.properties` :

gitPropertiesPluginVersion=2.5.7

آخر کار : Testcontainers صحنے میں آتا ہے

اب تک، یہ صرف 'build script debugging' تھا۔ ہر غلطی Gradle 9 یا Java 21 کی ناسازگوشی thi بیلڈ سکرپٹس میں۔ اوپر دیے گئے چھ ٹھیک کرنے کے بعد،`./gradlew assemble`کامیابی سے پاس کرتا ہے

لیکن`./gradlew build`یہ ٹیسٹس بھی چلاتا ہے اور کیوکربر ٹیسٹس ایک موقت پوسٹگریSQL চালانے کے لیے Testcontainers استعمال کرتے ہیں۔

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 سॉकेट) ایک ہی غلطی پر ناکام رہتی ہیں۔

@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

مرحلہ 1 : ڈاکر-جیوا ٹریک

پہلا رفلیکس: ٹیسٹ کونٹینرز کے استعمال ہونے والی جاووا ڈوکر کلائنٹ API کی ورژن بھیجتا ہے۔1.32`اس کے HTTP ہینڈشیک میں، لیکن Docker Engine 29.4.1 کم از کم طلب کرتا ہے`1.40. مشکل کلائنٹ کے سطح پر ہے، ڈیمون پر نہیں۔

Testcontainers 1.20.6 سے حل کردہ docker-java ورژن کی تصدیق :

$ ./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 سے منسوب. داکر-جا کی آخری عامی ورژن 3.5.1 ہے. ہم ورژن اپ گریڈ کرنے کی کوشش کرتے ہیں، ذریعے`resolutionStrategy`بلاک میں`configurations` de build.gradle:

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

بیَلڈ کی ری لاينچ۔ یہی خطا:`client version 1.32 is too old`.

Gradle کیش کی تصدیق: JARs کامیابی سے دوبارہ ڈاؤنلوڈ کر لیے گئے ہیں، لیکن خرابی مست ہے۔ docker-java 3.5.1 ابھی بھی بھیج رہا ہے`1.32`. یہ ورژن اس لیے Docker Engine 29.4.1 کے لیے کافی نہیں ہے۔

صافی کرنے کا عملGradle کیش کو مکمل طور پر صاف کریں، صرف یقینی کے لیے

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

پرج کے بعد مکمل ری استارت۔ ایک ہی غلطی۔

مرحلہ 2 : وéb تلاش اور GitHub کی بريكرumb

docker-java 3.5.1 کافی نہیں ہے. اب صرف یہ دیکھنا باقی ہے کہ کیا کسی نے اس Exact مسئلے کا سامنا کیا ہے۔

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`. ڈیمَن خوشِ اخلاق سے لیکن سختانه سے انکار کرتا ہے۔

mas’alah #11491 mein, ek muhawil jawab deta hai:

_ ہائے، میرا پروژیکٹ ورژن 2.0.3 کے ساتھ GH رنر پر انجن 29.1 کے ساتھ چل رہا ہے اور یہ کام کرتا ہے۔ کیا آپ سب براہِ مہربانی چیک کر سکتے ہیں کہ ورژن کے ساتھ کوئی تصادم نہیں ہے؟ براہِ کرم، یاد رکھیں کہ تمام ماڈیولز کا پیشوند لگایا گیا تھا`testcontainers-. لہذا، ورژن 2.x سے شروع کرتے ہوئے ہم …​ سے منتقل ہوگئے`postgresql to testcontainers-postgresql _

یہ جواب شامل ہےدو اہم معلومات:

  1. Testcontainers 2.0.3+ مسئلے کا حل کرتا ہے

  2. مائوڈولز ہوئے ہیںپرفکس کے ساتھ بدل دیے گئے `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

بدون تغيير

پہلی کوشش : Testcontainers BOM 2.0.5 لاگو کریں اور نئے آرٹیفیکٹ ناموں میں`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.

testcontainers-bom BOM کافی نہیں ہے۔کیوں؟ کیونکہ Spring Boot 3.4.5 اپنی خود کی BOM (اعتمادوں کی نظام) ظاہر کرتا ہے (spring-boot-dependencies) جوجیتاٹیسٹ کونٹینرز بی او ام کے بارے میں مترابط حل میں. سپرینگ بُوٹ سیٹ کرتا ہے.testcontainers à 1.20.6، اسلیے سب artifacts jo wazahat se Spring Boot BOM mein nahi hain (jaise naye`testcontainers-*) پرانے نام کی طرف حل کرتے ہیں`1.20.6-- jo is version mein ab nahi rehtay.

جائزہ لیتے وقت`dependencies --configuration testRuntimeClasspath`, پاتا ہے :

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

Le →`indique بدل کی اشارہ دیتا ہے: 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. Spring Boot BOM کو circumvent کرتے ہوئے Testcontainers core کو 2.0.5 تک force کریں

@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`یہ بوم کو باپس کرنے کا ایک صرف طریقہ ہے`spring-boot-dependencies`Spring Boot پلاگین کے ذریعے منظم. مساوات کا ٹیسٹ پر`details.requested.name == "testcontainers"`یہ عمداً محدود ہے: ہم صرف کور ماڈیول کو زبردست کرتے ہیں۔ ماڈیولات`testcontainers-*`انہوں نے Testcontainers 2.0.5 کے BOM کیپیروی کی ہے جو ہم نے صریحاً اعلان کیا ہے۔

آخری نتیجہ

$ ./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 اب تک اپنی PostgreSQL کنٹینرز بنانے میں کامیاب ہو گئیں Docker Engine 29.4.1 کے ذریعے۔ آخری کاروباری خرابی (Cucumber ٹیسٹ پر HTTP 500) ایک بالکل الگ استعمال ہونے والی سکرپٹ سے مستقل برنامے کی مسئلے ہے۔

ترمیمات کا خلاصہ جدول

# فائل مشکل تصحیح

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`بالی سطح ممنوع 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

گریڈل کیچ

docker-java 3.5.1 آزمائش کی گئی، حل ہو گیا لیکن کافی نہیں

صافی + گزر docker-java 3.7.1

8

build.gradle

Testcontainers 1.20.6 Docker Engine 29 کے ساتھ نامطابق

Testcontainers 2.0.5 + prefix لاجبڑ`testcontainers-*`+ resolutionStrategy مقابل Spring Boot BOM

نتیجہ

اگر آپ کا JHipster/Gradle بِلڈ گرائیل 9 + ڈاکر انجن 29 میں ورژن اپ گریڈ کے بعد خراب ہو جاتی ہے، تو خرابی دو درجے میں تقسیم ہوتی ہے :

بلڈ سکرپٹ کی غلطیاں(پہلے 6) : گرڈل 9 خصوصیات اور سائنٹکس کو حذف کر دیتی ہے جو سالوں سے چل رہی تھیں (sourceCompatibility=, main =, reportsDir) یہ میکانیائی ہجرت ہیں جب ہم نئی API کو جان لیتے ہیں

ڈاکر رن ٹائم کی خرابی(آخری دو) : Docker Engine 29.4.1، 1.40 سے کم API کلائنٹوں کو خارج کر دیتا ہے۔ Testcontainers 1.20.6 (Spring Boot 3.4.5 کے تحت مجبور) docker-java 3.4.1 استعمال کرتا ہے jo 1.32 API ورژن بھیجتا ہے۔ صرف Testcontainers 2.0.5 + docker-java 3.7.1 مسئلے کو حل کرتا ہے، آرتЕФАکٹوں کے نام بدل کر اور ورژن کو زبردست کر کے ذریعے`resolutionStrategy.eachDependency`Spring Boot کے ضمنی BOM کو منفی کرنے کا صرف ایک طریقہ

پروژه کی جڑ پر موجود Gradle بِلڈ اسکرپٹ اب صاف ہے۔./gradlew build`Java 21، Gradle 9.4.1، Spring Boot 3.4.5 اور Docker Engine 29.4.1 پر چلتا ہے۔

متعلقہ مضامین

HyperFrames-Gradle : Transformer l'AsciiDoc en Vidéo MP4
31 May 2026
میرے LLM استعمال کا آڈٹ: SQLite، OpenCode، Ollama Cloud، اور کیوں میری پرو سبسکرپشن عالمی مارکیٹ کو پیچھے چھوڑ رہی ہے
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