Gradle அதன் proxy அமைப்புகளை எங்கிருந்து பெறுகிறது

IDE-யிலிருந்து தொடங்கும் Gradle build, terminal-இலிருந்து தொடங்கும் அதே project-ஐவிட வேறு configuration-ஐப் பயன்படுத்தலாம். பழைய proxy process-ஐ குற்றம் சாட்டுவதற்கு முன் ஒவ்வொரு தொடக்கத்திலும் Gradle user home, JVM, proxy properties ஆகியவற்றை ஒப்பிடுங்கள்.

Gradle JVM proxy பண்புகளை ஆவணப்படுத்துகிறது

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 உள்ளதா பாருங்கள். ஒருவரின் configuration-இல் உள்ள proxy entry, மற்றொரு context ஏற்றியதைச் சொல்லாது.

மாற்றிய 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-ஐச் சரிபாருங்கள்.