sbt को पहिलो डाउनलोड प्रोक्सी मार्फत लिनुहोस्

तपाईंको बिल्ड परिभाषाले केही उपयोगी काम गर्नुअघि नै sbt लाई नेटवर्क चाहिन सक्छ। यसको लन्चरले कम्पोनेन्टहरू लिनुपर्छ, र बिल्डले पछि थप पुस्तकालयहरूमार्फत रिपोजिटरीहरूसँग सम्पर्क गर्न सक्छ। कुनै कार्यभित्र लुकाइएको प्रोक्सी सेटिङ पहिलो डाउनलोडका लागि धेरै ढिलो आउन सक्छ।

वास्तवमा sbt चलाउने JVM बाट सुरु गर्नुहोस्। परियोजनाको .jvmopts पढ्ने लन्चरका लागि आधारभूत एन्डपोइन्ट गुणहरू यी हुन सक्छन्:

-Dhttp.proxyHost=proxy.example.net
-Dhttp.proxyPort=8080
-Dhttps.proxyHost=proxy.example.net
-Dhttps.proxyPort=8080

यी मानहरूले होस्टनाम र पोर्ट छुट्याउँछन्; ती पूर्ण प्रोक्सी URL होइनन्। अनुमति प्राप्त सार्वजनिक रिपोजिटरी डाउनलोडका लागि HTTP प्रोक्सी सूची ले ती फिल्डका लागि सम्भावित मानहरू दिन्छ। HTTPS रिपोजिटरीमा CONNECT प्रयोग गरी HTTP प्रोक्सीमार्फत पनि पुग्न सकिन्छ।

कुन डाउनलोड असफल भयो ध्यान दिनुहोस्

लन्चर बुटस्ट्र्याप, बिल्ड-टुल कम्पोनेन्ट, प्लगइन र निर्भरताहरूले अनिवार्य रूपमा एउटै कन्फिगरेसन तह प्रयोग गर्दैनन्। रिपोजिटरी घोषणाहरू सम्पादन गर्नुअघि असफल URL र चरण पहिचान गर्नुहोस्।

रिपोजिटरी छनोटले कलाकृतिहरू कहाँबाट प्राप्त हुन्छन् भन्ने जवाफ दिन्छ। प्रोक्सी कन्फिगरेसनले नेटवर्क क्लाइन्टले त्यो एन्डपोइन्टमा कसरी पुग्छ भन्ने जवाफ दिन्छ। रिपोजिटरीलाई आन्तरिक मिररले प्रतिस्थापन गर्नु अलग समर्थित विकल्प हुन सक्छ, तर यसले अन्य सबै गन्तव्यहरूका लागि नेटवर्क प्रोक्सी कन्फिगर गर्दैन।

प्रोक्सी प्रमाणीकरण अर्को जाँच हो। प्रत्येक Java डाउनलोडरले कुनै पनि proxyUser गुणलाई समर्थित लगइन संयन्त्र मान्छ भनी नठान्नुहोस्। स्थापित लन्चर र सम्बन्धित रिजोल्भरका लागि कागजात गरिएको प्रमाणीकरण व्यवस्था प्रयोग गर्नुहोस्।

अन्तमा, अर्को रनरका लागि लेखिएको गाइडबाट भेरिएबल प्रतिलिपि गर्नुको सट्टा प्रभावकारी लन्चर वातावरण जाँच्नुहोस्। DNS असफलता, अनुपलब्ध रिपोजिटरी र अस्वीकृत प्रोक्सी लगइन—सबै निर्भरता समाधानका क्रममा देखा पर्न सक्छन्, तर तिनलाई धेरै फरक सुधार चाहिन्छ।