Gradle اپنی پراکسی ترتیبات کہاں سے لیتا ہے

IDE سے شروع کیا گیا Gradle build اسی project کے terminal سے شروع ہونے والے build سے مختلف configuration استعمال کر سکتا ہے۔ پرانے proxy process کو موردِ الزام ٹھہرانے سے پہلے ہر آغاز کے Gradle user home، JVM اور proxy properties کا موازنہ کریں۔

Gradle JVM proxy properties کو دستاویز کرتا ہے

HTTP اور HTTPS راستوں کے لیے properties file میں یہ ہو سکتا ہے:

systemProp.http.proxyHost=203.0.113.10
systemProp.http.proxyPort=8080
systemProp.https.proxyHost=203.0.113.10
systemProp.https.proxyPort=8080
systemProp.http.nonProxyHosts=localhost|*.example.internal

اپنا تفویض کردہ endpoint استعمال کریں؛ اجازت یافتہ public-repository راستوں کے لیے HTTP proxy list ممکنہ host اور port کے جوڑے دیتی ہے۔ HTTPS bypass property بھی http.nonProxyHosts ہے؛ https.nonProxyHosts گھڑنا دستاویزی حل نہیں۔ Host properties میں مکمل proxy URL نہیں بلکہ پتہ ہوتا ہے۔

Shell میں HTTP_PROXY export کرنا بذاتِ خود یہ ثابت نہیں کرتا کہ یہ JVM client اسے proxy policy کے طور پر استعمال کرتا ہے۔ Application کی supported properties دیکھیں۔

Daemon کو build کی معلومات ملتی ہیں

موجودہ Gradle documentation کے مطابق client environment variables سمیت build information daemon کو بھیجتا ہے۔ اس لیے “daemon کو کبھی نئے environment variables نہیں ملتے” ایک غلط عمومی وضاحت ہے۔

کچھ JVM startup properties، جن میں trust-store properties شامل ہیں، چلتے ہوئے JVM کے لیے ناقابلِ تبدیلی ہیں۔ اس لیے عام build environment values آگے بھیجی جائیں تب بھی بدلا ہوا Java home یا trust-store startup configuration اہم ہو سکتا ہے۔

دونوں آغاز کا موازنہ کریں

دیکھیں کہ IDE کون سا Gradle distribution اور Java runtime منتخب کرتا ہے۔ دیکھیں کہ وہ terminal جیسے ہی GRADLE_USER_HOME اور user properties استعمال کرتا ہے یا نہیں۔ ایک user کی configuration میں proxy entry سے معلوم نہیں ہوتا کہ دوسرے context نے کیا load کیا۔

اگر بدلی ہوئی startup requirement کو الگ daemon چاہیے تو متعلقہ Gradle version کے documented daemon controls استعمال کریں۔ غلط property یا غائب configuration file تلاش کرنے کے بجائے daemon کو نہ روکیں۔

آخر میں ناکام request کی شناخت کریں۔ Wrapper downloads، build dependency resolution اور forked application یا test processes کی requests خودبخود ایک ہی network context نہیں ہوتیں۔ Gradle property کے کنٹرول کی توقع سے پہلے request کرنے والے process کی تصدیق کریں۔