Gradle તેની પ્રોક્સી સેટિંગ્સ ક્યાંથી મેળવે છે
Gradleના JVM પ્રોક્સી ગુણધર્મો, વપરાશકર્તા home સેટિંગ્સ અને ક્લાયન્ટ પર્યાવરણને અનુસરો; daemon નવા variablesને હંમેશા અવગણે છે એવું ન માનો.
IDEમાંથી શરૂ કરાયેલ Gradle build ટર્મિનલમાંથી શરૂ કરાયેલા એ જ project કરતાં અલગ 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 નહીં, address હોય છે.
Shellમાં HTTP_PROXY export કરવાથી આ JVM client તેને proxy policy તરીકે વાપરે છે તે એકલું સાબિત થતું નથી. Application સપોર્ટ કરતી properties તપાસો.
Daemon build માહિતી મેળવે છે
વર્તમાન Gradle documentation કહે છે કે client environment variables સહિત build information daemonને મોકલે છે. તેથી “daemonને ક્યારેય નવા environment variables મળતા નથી” સામાન્ય સમજૂતી ખોટી છે.
Trust-store properties સહિત કેટલીક JVM startup 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 અથવા missing configuration file શોધવાના બદલે daemon બંધ ન કરો.
છેલ્લે નિષ્ફળ request ઓળખો. Wrapper downloads, build dependency resolution અને forked application અથવા test processની requests આપમેળે એક જ network context નથી. Gradle property તેને નિયંત્રિત કરશે એવી અપેક્ષા પહેલાં request કરતું process ચકાસો.