Gradle 5.0: كيفية إصلاح الميزات القديمة وتحديث مشروع Kotlin

لماذا يصرخ Gradle "ميزات قديمة" وماذا تفعل حيال ذلك؟

هل سبق لك أن قمت بتشغيل بناء مشروع Kotlin ورأيت رسالة مخيفة: تم استخدام ميزات Gradle القديمة في هذا البناء، مما يجعله غير متوافق مع Gradle 5.0؟ إذا كان الأمر كذلك، فأنت لست وحدك. هذا السؤال حصد آلاف المشاهدات على Stack Overflow، واليوم سنقوم بتحليله بالكامل.

تخيل: أنت تكتب بلغة Kotlin، كل شيء يعمل، ولكن فجأة يبدأ Gradle في التذمر. يقول: "مرحبًا، أنت تستخدم ميزات قديمة سأزيلها في الإصدار 5.0!". هذا يشبه أن تخبرك آلة القهوة المفضلة لديك أنها ستتوقف غدًا عن قبول الأكواب القديمة. إنه أمر مزعج، لكن يمكن حله.

في هذه المقالة، لن نعرض فقط كيفية إزالة الخطأ. سنقارن ثلاثة أساليب للحل: من الحل السريع "الترقيعي" إلى إعادة الهيكلة الاحترافية. ستعرف لماذا يعتبر Gradle الكود الخاص بك قديمًا، وكيفية إعادة كتابته بأسلوب حديث.

ما هي الميزات القديمة في Gradle؟

الوظائف القديمة (Deprecated) هي أجزاء من API التي يخطط مطورو Gradle لإزالتها في المستقبل. تم الاحتفاظ بها للتوافق مع الإصدارات السابقة، لكن لا يُنصح باستخدامها بعد الآن. عندما ترى هذا التحذير، فإن Gradle يقول حرفيًا: "سيتم بناء مشروعك الآن، ولكن بعد التحديث إلى الإصدار 5.0 - لا".

غالبًا ما تكمن المشكلة في:

\n
• الإضافات القديمة (مثل الإصدارات القديمة من kotlin-gradle-plugin)
\n
• التبعيات الضمنية (استخدام compile بدلاً من implementation)
\n
• النصوص البرمجية بلغة Groovy غير المتكيفة مع Kotlin DSL
\n
• الاستدعاءات المباشرة للطرق القديمة في build.gradle
\n

النهج 1: الحل السريع - كتم التحذيرات

أبسط طريق (وليس الأصح) هو فقط أن تقول لـ Gradle: "اخرس واعمل". هذا مثل لصق لمبة Check Engine بشريط لاصق. السيارة ستتحرك، لكن المشاكل ستبقى.

أضف إلى build.gradle.kts (Kotlin DSL) الكتلة التالية:

tasks.withType<Wrapper> {\n    gradleVersion = "4.10.3" // تجميد الإصدار\n}\n\n// أو كتم التحذير\nallprojects {\n    tasks.withType<AbstractCompile> {\n        options.isDeprecation = false\n    }\n}

الإيجابيات: سريع، لا يتطلب تغييرات في الكود، يتم البناء بنجاح.

السلبيات: أنت لا تحل المشكلة، بل تؤجلها فقط. عند الانتقال إلى Gradle 5.0+ سيتعطل المشروع. بالإضافة إلى ذلك، تفوت تحسينات مهمة في الأداء والأمان.

متى تستخدم: فقط إذا كنت بحاجة ماسة لبناء المشروع، وليس لديك وقت لإعادة الهيكلة. ولكن تأكد من التخطيط لحل مناسب.

النهج 2: الترحيل إلى التكوينات الحديثة

هذا هو "الوسط الذهبي". أنت لا تسد الخطأ فحسب، بل ترتب المشروع. دعنا نحلل المشاكل النموذجية باستخدام مثال مشروع Kotlin.

استبدال compile بـ implementation/api

الطريقة القديمة لإعلان التبعيات - compile - كانت قديمة منذ Gradle 3.0. بدلاً من ذلك، استخدم implementation و api.

كان (Groovy):

dependencies {\n    compile 'org.jetbrains.kotlin:kotlin-stdlib:1.3.72'\n    compile 'com.squareup.retrofit2:retrofit:2.9.0'\n}

أصبح (Kotlin DSL):

dependencies {\n    implementation("org.jetbrains.kotlin:kotlin-stdlib:1.9.0")\n    implementation("com.squareup.retrofit2:retrofit:2.9.0")\n}

الفرق بسيط: implementation يخفي التبعية عن مستهلكي الوحدة، مما يسرع البناء. api يجعلها مرئية، مثل compile القديم.

تحديث إضافة Kotlin

الإصدارات القديمة من kotlin-gradle-plugin غالبًا ما تستخدم API قديم لـ Gradle. تحقق من الإصدار الحالي على kotlinlang.org وقم بالتحديث