Gradle ತನ್ನ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಎಲ್ಲಿಂದ ಪಡೆಯುತ್ತದೆ

IDEಯಿಂದ ಪ್ರಾರಂಭಿಸಿದ Gradle build ಟರ್ಮಿನಲ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿದ ಅದೇ ಯೋಜನೆಗಿಂತ ವಿಭಿನ್ನ ಸಂರಚನೆಯನ್ನು ಬಳಸಬಹುದು. ಹಳೆಯ ಪ್ರಾಕ್ಸಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಪ್ರತಿಯೊಂದು ಪ್ರಾರಂಭದ Gradle user home, JVM ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೋಲಿಸಿ.

Gradle JVM ಪ್ರಾಕ್ಸಿ ಗುಣಲಕ್ಷಣಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ

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 ಬಳಸಿ; ಅನುಮತಿಸಲಾದ ಸಾರ್ವಜನಿಕ 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ಯಾಗಿ ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು ತಾನಾಗಿಯೇ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ಬೆಂಬಲಿಸುವ 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 ಏನು load ಮಾಡಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುವುದಿಲ್ಲ.

ಬದಲಾಗಿರುವ startup requirementಗೆ ಬೇರೆ daemon ಬೇಕಾದರೆ ಸಂಬಂಧಿಸಿದ Gradle versionನ documented daemon controls ಬಳಸಿ. ತಪ್ಪಾದ property ಅಥವಾ ಕಾಣೆಯಾದ configuration file ಹುಡುಕುವುದಕ್ಕೆ ಬದಲಾಗಿ daemon ನಿಲ್ಲಿಸಬೇಡಿ.

ಕೊನೆಯಲ್ಲಿ ವಿಫಲವಾದ request ಗುರುತಿಸಿ. Wrapper downloads, build dependency resolution ಮತ್ತು forked application ಅಥವಾ test processಗಳ requests ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಒಂದೇ network context ಆಗಿರುವುದಿಲ್ಲ. Gradle property ಅದನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸುವ ಮೊದಲು request ಮಾಡುವ process ಪರಿಶೀಲಿಸಿ.