Ang Gradle build na inilunsad mula sa IDE ay maaaring gumamit ng ibang configuration kaysa sa parehong project na inilunsad mula sa terminal. Bago sisihin ang lumang proxy process, paghambingin ang Gradle user home, JVM, at proxy properties ng bawat launch.

Idinodokumento ng Gradle ang JVM proxy properties

Para sa mga HTTP at HTTPS route, maaaring maglaman ang properties file ng:

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

Gamitin ang nakatalagang endpoint; para sa mga pinahihintulutang route sa public repository, nagbibigay ang HTTP proxy list ng mga posibleng pares ng host at port. Ang HTTPS bypass property ay http.nonProxyHosts din; ang pag-imbento ng https.nonProxyHosts ay hindi dokumentadong ayos. Address ang laman ng host properties, hindi buong proxy URL.

Ang pag-export ng HTTP_PROXY sa shell ay hindi sapat na patunay na ginagamit ito ng JVM client bilang proxy policy. Suriin ang mga property na sinusuportahan ng application.

Tumatanggap ng build information ang daemon

Ayon sa kasalukuyang Gradle documentation, ipinapadala ng client sa daemon ang build information, kabilang ang environment variables. Kaya hindi tumpak ang pangkalahatang paliwanag na “hindi kailanman tumatanggap ang daemon ng bagong environment variables.”

Hindi nababago sa tumatakbong JVM ang ilang JVM startup property, kabilang ang trust-store properties. Kaya maaaring mahalaga ang binagong Java home o trust-store startup configuration kahit ipinapasa ang karaniwang build-environment values.

Paghambingin ang dalawang launch

Tingnan kung aling Gradle distribution at Java runtime ang pinili ng IDE. Tingnan kung ginagamit nito ang kaparehong GRADLE_USER_HOME at user properties gaya ng terminal. Hindi ipinapakita ng proxy entry sa configuration ng isang user kung ano ang ni-load ng ibang context.

Kung kailangan ng ibang daemon dahil sa binagong startup requirement, gamitin ang dokumentadong daemon controls para sa bersyon ng Gradle. Huwag gawing kapalit ng paghahanap sa maling property o nawawalang configuration file ang paghinto sa daemon.

Panghuli, tukuyin ang nabigong request. Ang Wrapper downloads, build dependency resolution, at mga request mula sa forked application o test process ay hindi awtomatikong iisang network context. I-verify ang process na gumagawa ng request bago asahang kokontrolin ito ng Gradle property.

Kaugnay na mga artikulo