على Maven الوصول إلى إضافة الوكيل قبل أن يتمكن من تشغيلها

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

لا يُنفَّذ هدف الإضافة إلا بعد أن يتمكن Maven من حل تنفيذها والقطع المطلوبة وتحميلها. لا يمكن لاكتشاف الوكيل داخل ذلك التنفيذ أن يساعد في تنزيل يفشل قبل بدء التنفيذ. استخدام إحداثيات إضافة مؤهلة بالكامل قد يتجنب البحث بالبادئة؛ لكنه لا يجعل قطعة الإضافة تظهر في مستودع محلي فارغ.

توضح إضافة Autoproxy القديمة لـ Maven هذا التمييز. يصف ملف README الخاص بها اكتشاف الوكيل عبر proxy-vole، لكنه يصف أيضًا تثبيت الإضافة محليًا قبل استدعاء هدفها. اعتبر ذلك شرطًا مسبقًا لذلك التصميم تحديدًا، لا دليلًا على أن Maven يقرأ إعدادات PAC الخاصة بالمتصفح بشكل عام.

امنح أول عملية حل مسارًا صريحًا

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

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

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