Gradle എവിടെ നിന്നാണ് പ്രോക്സി ക്രമീകരണങ്ങൾ എടുക്കുന്നത്

IDE-യിൽ നിന്ന് ആരംഭിച്ച Gradle build, terminal-ൽ നിന്ന് ആരംഭിച്ച അതേ project-നേക്കാൾ വ്യത്യസ്ത configuration ഉപയോഗിക്കാം. പഴയ proxy process-നെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ഓരോ തുടക്കത്തിലും Gradle user home, JVM, proxy properties എന്നിവ താരതമ്യം ചെയ്യുക.

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 ഉപയോഗിക്കുക; അനുവദിച്ച public-repository വഴികൾക്ക് HTTP proxy list candidate 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 എന്താണ് 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 പരിശോധിക്കുക.