Gradle को अपनी प्रॉक्सी सेटिंग्स कहाँ से मिलती हैं

IDE से शुरू किया गया Gradle build उसी प्रोजेक्ट के टर्मिनल से शुरू किए गए build से अलग कॉन्फ़िगरेशन इस्तेमाल कर सकता है। पुराने प्रॉक्सी process को दोष देने से पहले हर शुरुआत में Gradle user home, JVM और प्रॉक्सी प्रॉपर्टी की तुलना करें।

Gradle JVM प्रॉक्सी प्रॉपर्टी को दस्तावेज़ित करता है

HTTP और HTTPS routes के लिए properties फ़ाइल में यह हो सकता है:

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 routes के लिए HTTP proxy list संभावित host और port pairs देती है। HTTPS bypass property भी http.nonProxyHosts है; https.nonProxyHosts गढ़ना documented fix नहीं है। Host properties में address होता है, पूरा proxy URL नहीं।

Shell में HTTP_PROXY export करना अपने आप यह साबित नहीं करता कि यह JVM client इसे proxy policy की तरह इस्तेमाल करता है। एप्लिकेशन जिन properties को support करता है उन्हें जाँचें।

Daemon को build की जानकारी मिलती है

मौजूदा Gradle documentation कहती है कि client environment variables समेत build information daemon को भेजता है। इसलिए “daemon को नई environment variables कभी नहीं मिलतीं” एक गलत सामान्य व्याख्या है।

कुछ JVM startup properties, जिनमें trust-store properties शामिल हैं, चल रहे JVM के लिए immutable होती हैं। इसलिए बदला हुआ Java home या trust-store startup configuration महत्वपूर्ण हो सकता है, भले ही सामान्य build-environment values आगे भेजी जाएँ।

दोनों launches की तुलना करें

जाँचें कि 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 इस्तेमाल करें। Daemon रोकना गलत property या missing configuration file ढूँढने का विकल्प नहीं है।

अंत में असफल request पहचानें। Wrapper downloads, build dependency resolution और forked application या test processes की requests अपने आप एक ही network context नहीं होतीं। Gradle property से उसे नियंत्रित करने की उम्मीद से पहले request करने वाली process जाँचें।