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 ناکامی، دستیاب نہ ہونے والی ریپوزٹری اور مسترد شدہ پراکسی لاگ ان—سب انحصار کے حل کے دوران ظاہر ہو سکتے ہیں، مگر اِن کے لیے بہت مختلف اصلاحات درکار ہیں۔