Maven کو پراکسی پلگ ان چلانے سے پہلے اس تک پہنچنا ہوتا ہے

نیٹ ورکس کے درمیان گھومنے والے لیپ ٹاپ کے لیے خودکار پراکسی پلگ ان مثالی لگتا ہے۔ لیکن ایک مشکل پہلی درخواست ہے: Maven کو خود پلگ ان حاصل کرنے کے لیے پراکسی کی ضرورت پڑ سکتی ہے۔

پلگ ان کا ہدف اسی وقت چلتا ہے جب Maven اس کا نفاذ اور مطلوبہ آرٹی فیکٹ حل کر کے لوڈ کر لے۔ اس نفاذ کے اندر پراکسی کی دریافت ایسی ڈاؤن لوڈ کی مدد نہیں کر سکتی جو نفاذ شروع ہونے سے پہلے ناکام ہو جائے۔ مکمل طور پر اہل پلگ ان کوآرڈینیٹ استعمال کرنے سے سابقہ تلاش سے بچا جا سکتا ہے؛ مگر یہ خالی مقامی ذخیرے میں پلگ ان آرٹی فیکٹ ظاہر نہیں کرتا۔

پرانا Autoproxy Maven پلگ ان اسی فرق کو دکھاتا ہے۔ اس کا README proxy-vole کے ذریعے پراکسی کی دریافت بیان کرتا ہے، مگر اپنے ہدف کو کال کرنے سے پہلے پلگ ان کو مقامی طور پر نصب کرنے کا بھی بیان کرتا ہے۔ اسے اسی مخصوص ڈیزائن کی پیش شرط سمجھیں، اس بات کا ثبوت نہیں کہ Maven عام طور پر براؤزر کی PAC ترتیبات پڑھتا ہے۔

پہلے حل کو واضح راستہ دیں

جس نیٹ ورک میں ذخیرے تک رسائی کے لیے HTTP پراکسی درکار ہو، اس کال کی استعمال کردہ Maven ترتیبات میں مناسب فعال پراکسی ترتیب دیں. اجازت شدہ عوامی ذخیرے کے بوٹ اسٹریپ کے لیے، HTTP پراکسی فہرست سے HTTP امیدوار منتخب کریں۔ بیرونی راستے کے بغیر قابل رسائی منظور شدہ اندرونی ذخیرہ بھی ابتدائی رسائی کا مسئلہ حل کر سکتا ہے۔ کسی بھی طریقے کو پلگ ان اور اس کے انحصارات کا احاطہ کرنا چاہیے، صرف ایپلیکیشن کے انحصارات نہیں۔

پہلے سے بھرا مقامی ذخیرہ بوٹ اسٹریپ کی ضرورت چھپا سکتا ہے۔ ڈویلپر کے لیپ ٹاپ پر کامیابی یہ ثابت نہیں کرتی کہ نیا CI اکاؤنٹ وہی بلڈ شروع کر سکتا ہے۔ پلگ ان کی تشخیص کی منطق بدلنے سے پہلے ناکام آرٹی فیکٹ اور مرحلہ دیکھیں۔

پلگ ان لوڈ ہونے کے بعد، بعد میں انحصار کی ناکامی ایک الگ سوال بن جاتی ہے: آیا دریافت شدہ راستہ درست ہے اور آیا فعال Maven ٹرانسپورٹ نتیجے میں آنے والی ترتیبات استعمال کرتا ہے۔ خودکار تشخیص کو برقرار رکھنے کے قابل ہے یا نہیں، یہ فیصلہ کرتے وقت ان دو ناکامی کے مقامات کو الگ رکھیں۔