Gradle తన ప్రాక్సీ సెట్టింగ్లను ఎక్కడి నుంచి పొందుతుంది
Gradle JVM ప్రాక్సీ లక్షణాలు, వినియోగదారు home సెట్టింగ్లు, క్లయింట్ వాతావరణాన్ని అనుసరించండి; daemon కొత్త వేరియబుల్స్ను ఎప్పుడూ పట్టించుకోదని అనుకోకండి.
IDE నుంచి ప్రారంభించిన Gradle build, terminal నుంచి ప్రారంభించిన అదే 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ను ధృవీకరించండి.