Dari mana Gradle mendapatkan tetapan proksinya

Jejaki sifat proksi JVM Gradle, tetapan home pengguna dan persekitaran klien, bukannya menganggap daemon sentiasa mengabaikan pemboleh ubah baharu.

Binaan Gradle yang dilancarkan daripada IDE boleh menggunakan konfigurasi berbeza daripada projek yang sama dilancarkan dari terminal. Sebelum menyalahkan proses proksi lama, bandingkan home pengguna Gradle, JVM dan sifat proksi setiap pelancaran.

Gradle mendokumenkan sifat proksi JVM

Untuk laluan HTTP dan HTTPS, fail sifat boleh mengandungi:

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 titik akhir yang diperuntukkan; bagi laluan repositori awam yang dibenarkan, senarai proksi HTTP menyediakan pasangan hos dan port calon. Sifat pintasan HTTPS juga http.nonProxyHosts; mencipta https.nonProxyHosts bukan pembaikan yang didokumenkan. Sifat hos mengandungi alamat, bukan URL proksi lengkap.

Mengeksport HTTP_PROXY dalam shell tidak dengan sendirinya membuktikan klien JVM ini menggunakannya sebagai dasar proksi. Semak sifat yang disokong aplikasi.

Daemon memang menerima maklumat binaan

Dokumentasi Gradle semasa menyatakan bahawa klien menghantar maklumat binaan, termasuk pemboleh ubah persekitaran, kepada daemon. Oleh itu penjelasan umum “daemon tidak pernah menerima pemboleh ubah persekitaran baharu” tidak tepat.

Sesetengah sifat permulaan JVM, termasuk sifat stor amanah, tidak berubah untuk JVM yang sedang berjalan. Java home atau konfigurasi permulaan stor amanah yang berubah boleh penting walaupun nilai persekitaran binaan biasa diteruskan.

Bandingkan kedua-dua pelancaran

Semak pengedaran Gradle dan runtime Java yang dipilih IDE. Semak sama ada ia menggunakan GRADLE_USER_HOME dan sifat pengguna yang sama seperti terminal. Entri proksi dalam konfigurasi seorang pengguna tidak menunjukkan perkara yang dimuatkan konteks lain.

Jika keperluan permulaan yang berubah memerlukan daemon lain, gunakan kawalan daemon yang didokumenkan untuk versi Gradle berkenaan. Jangan jadikan penghentian daemon sebagai ganti untuk mencari sifat yang salah atau fail konfigurasi yang hilang.

Akhir sekali, kenal pasti permintaan yang gagal. Muat turun Wrapper, penyelesaian kebergantungan binaan dan permintaan proses aplikasi atau ujian bercabang bukan secara automatik satu konteks rangkaian. Sahkan proses yang membuat permintaan sebelum mengharapkan sifat Gradle mengawalnya.

Artikel berkaitan