تحسين إدارة مهام Gradle باستخدام Kotlin DSL و buildSrc
Publié le 11 July 2025
أتمتة مهام البناء أمر بالغ الأهمية لأي مشروع برمجي، و Gradle، مع DSL Kotlin الخاص به، يوفر مرونة استثنائية. خلال محادثتنا، استكشفنا كيفية تركيز وإعادة استخدام منطق البناء، خاصة لتقارير الاختبارات، بالاستفادة منجميع المشاريع, مصدر البناء, ومهام مخصصة في Kotlin.
مركز التكوينات مع allprojects و `subprojects
الكتل`allprojects` et `subprojects`فيك`build.gradle.kts`الجذور أساسية لتطبيق التكوينات المشتركة عبر مشروعك المتعدد الوحدات.
*allprojects { … }: طبّق الإعداد علىالمشروع الجذري وجميع مشاريعه الفرعية. مثالي لتحديد`group`,version, أو بعض`repositories`مشتركة. *subprojects { … }: تطبيق الإعداداتفقط للمشاريع الفرعية, باستثناء المشروع الجذري. مثالي لتطبيق الإضافات الخاصة بالوحدات (مثل`java` ou kotlin-jvm) أو تبعيات مشتركة لمكتباتك.
هذا مثال توضيحي:
// build.gradle.kts (projet racine)
plugins {
base // Appliqué au projet racine
}
allprojects {
group = "com.example"
version = "1.0.0"
repositories {
mavenCentral()
}
tasks.withType<org.gradle.api.tasks.testing.Test> {
useJUnitPlatform() // Configuration commune des tests pour tous les projets
}
}
subprojects {
apply(plugin = "java")
apply(plugin = "org.jetbrains.kotlin.jvm")
dependencies {
implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8")
}
}\== buildSrc: السكين السويسري لمنطق البناء
عندما يصبح منطق مهامك معقدًا أو يجب إعادة استخدامه،buildSrcهو الحل المفضَّل. هو وحدة Gradle خاصة يتم تجميعها قبل سكريبتات البناء الرئيسية، مما يجعل فئاتها متاحة على مسار الفئة لجميع بنائك.
لماذا تستخدم`buildSrc`python print(" \u0644\u0627\u0644\u0645\u0647\u0627\u0645\u061F", end='')
-
إعادة الاستخدام: مهمة محددة في`buildSrc`يمكن تطبيقها على أي مشروع في عملية البناء
-
منظمة: يُركّز كود البناء، مما يجعله أنظف وأكثر قابلية للصيانة.
-
سلامة النوع والإكمال التلقائي: الكود Kotlin في`buildSrc`تم تجميعه، مقدمًا التحقق من الأخطاء وإكمال الكود التلقائي في بيئة التطوير المتكاملة (IDE) الخاصة بك، مما يحسن تجربة التطوير.
\=== مخطط تدفق`buildSrc`(كود PlantUML)
لإنشاء هذا الرسم التخطيطي، انسخ الكود أدناه والصقه في أداة تدعم PlantUML.
[source,plantuml]
@startuml skinparam خط اليد صحيح skinparam أحادي اللون صحيح
مستطيل "Gradle Build Process" { component "buildSrc" as BS { ملف "MyCustomTask.kt" كـ T ملف "MyConventionPlugin.kt" كـ P } المكون "Root Project" كـ RP المكون "Subproject A" كـ SA المكوّن "Subproject B" كـ SB }
T --\> P : "معرّف في P --\> RP : "يتم تطبيقه على P -→ SA : "يُطبق على P -→ SB : "يُطبق على
RP --|\> SA : "يحتوي RP --|\> SB : "يحتوي
RP -up-\> BS : "يعتمد على (لمنطق البناء) SA -up-\> BS : "يعتمد على (لمنطق البناء) SB -up-\> BS : "يعتمد على (لمنطق البناء)
ملاحظة إلى اليمين من T فئات المهام المخصصة (exemple: OpenTestReportTask) ملاحظة النهاية
ملاحظة إلى اليمين من P ملحقات الاتفاق الذين يسجلون المهام ملاحظة النهاية
@enduml
\== Création de Tâches de Rapport Abstraites
لإدارة تقارير الاختبارات، صممنا نهجًا مودوليًا باستخدام فئة مهمة مجردة في`buildSrc`حسب احتياجاتك، يمكن لهذه الفئة أن ترث من`DefaultTask` ou de Exec.
مهمة مجردة`OpenTestReportTask`(وارث من`DefaultTask`)
يوصى باستخدام هذه الطريقة إذا كنت بحاجة إلى منطق Kotlin مخصص يتفاعل مع نظام الملفات أو واجهات برمجة تطبيقات Gradle الأخرى، ثم يقوم بتنفيذ أمر خارجي.