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-ის უკმარისობა, მიუწვდომელი საცავი და უარყოფილი პროქსის შესვლა ყველა შეიძლება გამოჩნდეს დამოკიდებულებების გადაწყვეტისას, მაგრამ მოითხოვს ძალიან განსხვავებულ შესწორებებს.

დაკავშირებული სტატიები