Gradle ໄດ້ຄ່າພຣັອກຊີຈາກໃສ

Gradle build ທີ່ເລີ່ມຈາກ IDE ອາດໃຊ້ການກຳນົດຄ່າຕ່າງຈາກໂຄງການດຽວກັນທີ່ເລີ່ມຈາກ terminal. ກ່ອນໂທດຂະບວນການພຣັອກຊີເກົ່າ ໃຫ້ປຽບທຽບ Gradle user home, JVM ແລະຄຸນສົມບັດພຣັອກຊີຂອງແຕ່ລະການເລີ່ມ.

Gradle ບັນທຶກຄຸນສົມບັດພຣັອກຊີ JVM

ສຳລັບເສັ້ນທາງ HTTP ແລະ HTTPS ໄຟລ໌ properties ອາດມີ:

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 ໃຫ້ຄູ່ host ແລະ port ທີ່ເປັນໄປໄດ້. HTTPS bypass property ກໍແມ່ນ http.nonProxyHosts; ການສ້າງ https.nonProxyHosts ບໍ່ແມ່ນວິທີແກ້ທີ່ມີເອກະສານ. Host properties ມີທີ່ຢູ່ ບໍ່ແມ່ນ proxy URL ເຕັມ.

ການ export HTTP_PROXY ໃນ shell ບໍ່ພິສູດດ້ວຍຕົວເອງວ່າ JVM client ນີ້ໃຊ້ມັນເປັນ proxy policy. ກວດຄຸນສົມບັດທີ່ application ຮອງຮັບ.

Daemon ໄດ້ຮັບຂໍ້ມູນ build

Gradle documentation ປັດຈຸບັນລະບຸວ່າ client ສົ່ງ build information ລວມ environment variables ໃຫ້ daemon. ດັ່ງນັ້ນຄຳອະທິບາຍທົ່ວໄປວ່າ “daemon ບໍ່ເຄີຍໄດ້ environment variables ໃໝ່” ບໍ່ຖືກຕ້ອງ.

JVM startup properties ບາງຢ່າງ ເຊັ່ນ trust-store properties ປ່ຽນບໍ່ໄດ້ສຳລັບ JVM ທີ່ກຳລັງເຮັດງານ. ດັ່ງນັ້ນ Java home ຫຼື trust-store startup configuration ທີ່ປ່ຽນອາດສຳຄັນ ເຖິງແມ່ນ build environment values ປົກກະຕິຈະຖືກສົ່ງຕໍ່.

ປຽບທຽບການເລີ່ມສອງແບບ

ກວດວ່າ IDE ເລືອກ Gradle distribution ແລະ Java runtime ໃດ. ກວດວ່າໃຊ້ GRADLE_USER_HOME ແລະ user properties ດຽວກັນກັບ terminal ຫຼືບໍ່. Proxy entry ໃນ configuration ຂອງ user ຄົນໜຶ່ງບໍ່ບອກວ່າ context ອື່ນໂຫຼດຫຍັງ.

ຖ້າ startup requirement ທີ່ປ່ຽນຕ້ອງການ daemon ອື່ນ ໃຫ້ໃຊ້ documented daemon controls ຂອງ Gradle version ນັ້ນ. ຢ່າໃຊ້ການຢຸດ daemon ແທນການຊອກຫາ property ຜິດ ຫຼື configuration file ທີ່ຫາຍໄປ.

ສຸດທ້າຍ ລະບຸ request ທີ່ລົ້ມເຫຼວ. Wrapper downloads, build dependency resolution ແລະ requests ຈາກ forked application/test processes ບໍ່ແມ່ນ network context ດຽວກັນໂດຍອັດຕະໂນມັດ. ກວດ process ທີ່ເຮັດ request ກ່ອນຄາດຫວັງວ່າ Gradle property ຈະຄວບຄຸມມັນ.