sbt का पहला डाउनलोड प्रॉक्सी के ज़रिए पाएँ

आपकी बिल्ड परिभाषा कुछ उपयोगी करने से पहले sbt को नेटवर्क की ज़रूरत पड़ सकती है। इसके लॉन्चर को घटक प्राप्त करने होते हैं, और बिल्ड बाद में अतिरिक्त लाइब्रेरी के ज़रिए रिपॉज़िटरी से संपर्क कर सकता है। किसी टास्क के भीतर छिपी प्रॉक्सी सेटिंग पहले डाउनलोड के लिए बहुत देर से आ सकती है।

उस JVM से शुरू करें जो वास्तव में sbt चलाता है। ऐसे लॉन्चर के लिए जो प्रोजेक्ट का .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 विफलता, अनुपलब्ध रिपॉज़िटरी और अस्वीकृत प्रॉक्सी लॉगिन—सभी निर्भरता समाधान के दौरान दिख सकते हैं, पर उनके लिए बहुत अलग सुधार चाहिए।