तुमची बिल्ड व्याख्या काही उपयुक्त करण्यापूर्वी 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 अपयश, अनुपलब्ध रेपॉझिटरी आणि नाकारलेला प्रॉक्सी लॉगिन—हे सर्व अवलंबनता सोडवताना दिसू शकतात, पण त्यांना खूप वेगळ्या दुरुस्त्या लागतात.

संबंधित लेख