Dari mana Gradle mendapatkan setelan proksinya

Lacak properti proksi JVM Gradle, setelan home pengguna, dan lingkungan klien, bukan menganggap daemon selalu mengabaikan variabel baru.

Build Gradle yang diluncurkan dari IDE dapat memakai konfigurasi berbeda dari proyek yang sama saat diluncurkan dari terminal. Sebelum menyalahkan proses proksi lama, bandingkan home pengguna Gradle, JVM, dan properti proksi pada setiap peluncuran.

Gradle mendokumentasikan properti proksi JVM

Untuk rute HTTP dan HTTPS, berkas properti dapat berisi:

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

Gunakan endpoint yang ditetapkan; untuk rute repositori publik yang diizinkan, daftar proksi HTTP menyediakan pasangan host dan port kandidat. Properti bypass HTTPS juga http.nonProxyHosts; membuat https.nonProxyHosts bukan perbaikan yang didokumentasikan. Properti host berisi alamat, bukan URL proksi lengkap.

Mengekspor HTTP_PROXY di shell tidak dengan sendirinya membuktikan bahwa klien JVM ini menggunakannya sebagai kebijakan proksi. Periksa properti yang didukung aplikasi.

Daemon memang menerima informasi build

Dokumentasi Gradle saat ini menyatakan bahwa klien mengirim informasi build, termasuk variabel lingkungan, ke daemon. Jadi penjelasan umum “daemon tidak pernah menerima variabel lingkungan baru” tidak akurat.

Beberapa properti startup JVM, termasuk properti trust store, tidak dapat diubah pada JVM yang sedang berjalan. Karena itu Java home atau konfigurasi startup trust store yang berubah dapat berpengaruh meskipun nilai lingkungan build biasa diteruskan.

Bandingkan kedua peluncuran

Periksa distribusi Gradle dan runtime Java yang dipilih IDE. Periksa apakah IDE menggunakan GRADLE_USER_HOME dan properti pengguna yang sama seperti terminal. Entri proksi di konfigurasi satu pengguna tidak menunjukkan apa yang dimuat konteks lain.

Jika kebutuhan startup yang berubah memerlukan daemon berbeda, gunakan kontrol daemon yang didokumentasikan untuk versi Gradle terkait. Jangan menjadikan penghentian daemon sebagai pengganti pencarian properti yang salah atau berkas konfigurasi yang hilang.

Terakhir, identifikasi permintaan yang gagal. Unduhan Wrapper, resolusi dependensi build, dan permintaan dari proses aplikasi atau pengujian bercabang tidak otomatis berada dalam satu konteks jaringan. Verifikasi proses yang membuat permintaan sebelum berharap properti Gradle mengendalikannya.

Artikel terkait