नेटवर्कबीच घुम्ने ल्यापटपका लागि स्वचालित प्रोक्सी प्लगइन आदर्श सुनिन्छ। तर एउटा असहज पहिलो अनुरोध छ: Maven लाई प्लगइन आफैं प्राप्त गर्न प्रोक्सी चाहिन सक्छ।

Maven ले त्यसको कार्यान्वयन र आवश्यक आर्टिफ्याक्टहरू समाधान गरी लोड गरेपछि मात्र प्लगइन लक्ष्य चल्छ। त्यस कार्यान्वयनभित्रको प्रोक्सी पत्ता लगाउने कामले कार्यान्वयन सुरु हुनुअघि असफल हुने डाउनलोडलाई मद्दत गर्न सक्दैन। पूर्ण रूपमा योग्य प्लगइन निर्देशांक प्रयोग गर्दा प्रिफिक्स खोजीबाट बच्न सकिन्छ; तर खाली स्थानीय भण्डारमा प्लगइन आर्टिफ्याक्ट देखा पार्दैन।

पुरानो Autoproxy Maven प्लगइनले यो भिन्नता देखाउँछ। यसको README ले proxy-vole मार्फत प्रोक्सी पत्ता लगाउने वर्णन गर्छ, तर आफ्नो लक्ष्य बोलाउनु अघि प्लगइन स्थानीय रूपमा स्थापना गर्ने पनि वर्णन गर्छ। त्यसलाई त्यो विशेष डिजाइनको पूर्वशर्त मान्नुहोस्, Maven ले सार्वभौमिक रूपमा ब्राउजरको PAC सेटिङ पढ्छ भन्ने प्रमाण होइन।

पहिलो समाधानलाई स्पष्ट मार्ग दिनुहोस्

जुन नेटवर्कमा भण्डार पहुँचका लागि HTTP प्रोक्सी चाहिन्छ, त्यस कलले प्रयोग गर्ने Maven सेटिङमा उपयुक्त सक्रिय प्रोक्सी कन्फिगर गर्नुहोस्। अनुमति प्राप्त सार्वजनिक-भण्डार बुटस्ट्र्यापका लागि, HTTP प्रोक्सी सूचीबाट HTTP उम्मेदवार छान्नुहोस्। बाह्य मार्गबिना पुग्न सकिने स्वीकृत आन्तरिक भण्डारले पनि सुरुवाती पहुँच समस्या समाधान गर्न सक्छ। कुनै पनि दृष्टिकोणले प्लगइन र त्यसका निर्भरताहरू समेट्नुपर्छ, अनुप्रयोगका निर्भरताहरू मात्र होइन।

पहिले भरिएको स्थानीय भण्डारले बुटस्ट्र्याप आवश्यकता लुकाउन सक्छ। विकासकर्ताको ल्यापटपमा सफलता नयाँ CI खाताले त्यही बिल्ड सुरु गर्न सक्छ भन्ने प्रमाण होइन। प्लगइनको पत्ता लगाउने तर्क बदल्नुअघि असफल आर्टिफ्याक्ट र चरण हेर्नुहोस्।

प्लगइन लोड भएपछि, पछिको निर्भरता असफलता छुट्टै प्रश्न बन्छ: पत्ता लगाइएको मार्ग सही छ कि छैन र सक्रिय Maven यातायातले परिणामस्वरूप सेटिङ प्रयोग गर्छ कि गर्दैन। स्वचालित पत्ता लगाउने राख्न लायक छ कि छैन भन्ने निर्णय गर्दा ती दुई असफलता बिन्दु अलग राख्नुहोस्।

सम्बन्धित लेखहरू