تسخين الخلل في تبعية مكتبة الطرف الثالث

Question

لقد وجدت خطأ بسيط في إطار تطبيق أكبر أستخدمه. يتطلب التثبيت فقط تغيير سطرين في فئة واحدة. لقد أصلحت المشكلة ودفعت التغييرات على مستودع المشروع.

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

• بناء المشروع: هذا أجد صعوبة للغاية ، لا يمكنني حتى أن أبنيه بشكل صحيح لأن العديد من اختبارات الوحدة مكسورة في مستودع اللقطة ، وحتى بدون اختبارات الوحدة ، لا أكون بعيدًا جدًا لأنني أفتقد بعض التبعيات التي لا يمكن العثور عليها في مافن سنترال. أيضًا ، أحتاج إلى إرسال النسخة الثابتة إلى كل مطور آخر لأنه لا يمكن العثور عليه في Maven Central. (نحن نعمل على الشبكة وليس لدينا رابطة خاصة بنا.)

• إضافة وحدة جديدة إلى مشروعي حيث أحتفظ بنسخة من الفصل الذي قمت بإصلاحه. أقوم بعد ذلك بإضافة هذه الوحدة على أنها تبعية لجميع الوحدات التي يجب أن تستخدم نسخة تجاوز الفئة. ولكن كيف تحدد JVM الفئة التي يتم تحميلها بالفعل؟ سوف تجد اثنين إناء-الطرفي الذي يحتوي على فئة تحمل نفس الاسم. أي واحد سوف يتم تحميله بالفعل؟ إذا كان بإمكاني القيام بهذا العمل ، فسيسمح لي ذلك بدمج الإصدار المعدل من الفصل مع مشروعي بحيث يمكنني توزيع التصحيح مع المشروع وبمجرد إصلاح الأخطاء ، يمكنني ببساطة إزالة الوحدة النمطية.

• أنا بما في ذلك ملف الفئة المعدلة في الوحدة المصابة نفسها. حتى الآن ، يبدو أن هذا الحل الأسهل بالنسبة لي لأن JVM ستعمل دائمًا على تحميل الفصل من نفس الجرة أولاً. (هل أنا على حق؟ على الأقل هذا ما لاحظته في اختباراتي.)

شكرا على أي مدخلات على هذا.

Answer 1

انتهى بي الأمر إلى بناء المشروع بشكل منفصل ونقل هذا الإصدار إلى مساحة اسم أخرى. هذا ليس من غير المألوف. على سبيل المثال ، يحتفظ Hibernate CGLIB في مساحة الاسم الخاصة به من أجل تجنب تعارضات الإصدار بسبب تغييرات API.

• واجه الحل الأول المقترح مشكلة عندما تم استخدام المشروع الذي استخدمته أيضًا في تبعية أخرى ما أدى إلى ذلك الإصدار المعدل و عادي كانت النسخة على مسار الفصل ما الذي أدى إلى سلوك غريب للغاية بسبب تسمية الصراعات.

• كان للاقتراح الثاني والثالث مشاكل مماثلة كاقتراح أول. بالإضافة إلى ذلك ، كسرت التوافق مع إصدارات أخرى من التبعية.

حتى أنه يبدو مؤلمًا: إن الخروج من مساحة الاسم وتوفير بناء منفصل أمر لا بد منه ، حتى لو قمت بتغيير بضعة أسطر من التعليمات البرمجية فقط.

Answer 2

أعتقد أن نقل تبعيات مشروعك إلى مساحات أسماء مخصصة ليس مثاليًا ، لعدة أسباب:

• من المحتمل ألا يتم إعادة تعديلاتك إلى المطورين الأصليين للاعتماد.
• سيكون من الصعب مواكبة إصدارات التبعية الجديدة ، لذلك لا يوجد المزيد من عمليات الإثبات ، ولا توجد ميزات جديدة ، ولا توجد إصلاحات من مطوري الطرف الثالث والمساهمين.
• تجربتي هي أنه بمرور الوقت يتم نسيانه كيف و لماذا تم تعديل التبعية الأسماء المخصصة. سيؤدي هذا إلى عدم إهمال هذا الجزء من المشروع فحسب ، بل أيضًا لا يمكن المساس به ، حيث لن يعرف أحد ما الذي سيكسر عند استبداله.

أوافق على أن سير العمل باستخدام JitPack هو الحل الأفضل. كتبت منشورًا مدونة مع دليل مفصل للقيام بذلك مع بضع دقائق فقط من النفقات العامة: https://5am.technology/2016/12/fix-bugs-third-party-dependency-jitpack/

Answer 3

TL ؛ DR ؛

يزور https://jitpack.io وقراءة كيف يعمل

---

خطوات لحل المشكلة

لنفترض أن مكتبة الجهات الخارجية موجودة على جيثب ، ما عليك سوى استنساخ المشروع ، وإصلاحه.

ثم استخدام https://jitpack.io. JitPack ينشئ .jar من ريبو الخاص بك (حيث تقوم بإصلاح الكود) وينشئ الاعتماد عليك

<dependency>
    <groupId>GITHUB_USER</groupId>
    <artifactId>REPOSITORY</artifactId>
    <version>COMMIT</version>
</dependency>

كما تحتاج إلى إضافة هذا المستودع البعيد صراحة

<repositories>
    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>
</repositories>

• العمل السريع
• بسيط للقيام به
• بسيط للتراجع