Ստացեք sbt-ի առաջին ներբեռնումը պրոքսիի միջոցով

sbt-ին կարող է ցանց անհրաժեշտ լինել նախքան ձեր build-ի սահմանումը որևէ օգտակար բան կանի։ Դրա գործարկիչը պետք է ստանա բաղադրիչներ, և build-ը կարող է ավելի ուշ կապվել պահոցների հետ լրացուցիչ գրադարանների միջոցով։ Առաջադրանքի ներսում թաքնված պրոքսիի կարգավորումը կարող է շատ ուշ հասնել առաջին ներբեռնման համար։

Սկսեք այն JVM-ից, որն իրականում գործարկում է sbt-ն։ Նախագծի .jvmopts-ը կարդացող գործարկիչի համար հիմնական վերջնակետային հատկությունները կարող են լինել՝

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

Այս արժեքները բաժանում են հոսթի անունը և պորտը. դրանք ամբողջական պրոքսի URL չեն։ Թույլատրված հանրային պահոցների ներբեռնումների համար HTTP պրոքսիների ցանկը տալիս է թեկնածու արժեքներ այդ դաշտերի համար։ HTTPS պահոցին դեռ կարելի է հասնել HTTP պրոքսիի միջոցով՝ օգտագործելով CONNECT։

Ուշադրություն դարձրեք, թե որ ներբեռնումը ձախողվեց

Գործարկիչի bootstrap-ը, build-գործիքի բաղադրիչները, պլագինները և կախվածությունները պարտադիր չէ, որ օգտագործեն նույն կարգավորման շերտը։ Նախքան պահոցների հայտարարությունները խմբագրելը պարզեք ձախողված URL-ը և փուլը։

Պահոցի ընտրությունը պատասխանում է, թե որտեղից են ստացվում արտեֆակտները։ Պրոքսիի կարգավորումը պատասխանում է, թե ինչպես է ցանցային հաճախորդը հասնում այդ վերջնակետին։ Պահոցը ներքին հայելիով փոխարինելը կարող է առանձին աջակցվող ընտրություն լինել, բայց այն ցանցային պրոքսի չի կարգավորում մյուս բոլոր նպատակակետերի համար։

Պրոքսիի նույնականացումը ևս մեկ ստուգում է։ Մի ենթադրեք, որ յուրաքանչյուր Java ներբեռնիչ կամայական proxyUser հատկությունը դիտարկում է որպես աջակցվող մուտքի մեխանիզմ։ Օգտագործեք տեղադրված գործարկիչի և համապատասխան լուծիչի համար փաստաթղթավորված նույնականացման կարգը։

Վերջապես, ստուգեք գործարկիչի փաստացի միջավայրը՝ փոխարենը մեկ այլ runner-ի համար նախատեսված ուղեցույցից փոփոխական պատճենելու։ DNS-ի ձախողումը, անհասանելի պահոցը և մերժված պրոքսի մուտքը կարող են բոլորը ի հայտ գալ կախվածությունների լուծման ընթացքում, բայց պահանջում են շատ տարբեր ուղղումներ։