Gradle รับการตั้งค่าพร็อกซีจากที่ใด

Gradle build ที่เปิดจาก IDE อาจใช้การตั้งค่าต่างจากโปรเจกต์เดียวกันที่เปิดจากเทอร์มินัล ก่อนโทษกระบวนการพร็อกซีเก่า ให้เปรียบเทียบ Gradle user home, JVM และคุณสมบัติพร็อกซีของการเปิดแต่ละครั้ง

Gradle มีเอกสารสำหรับคุณสมบัติพร็อกซีของ JVM

สำหรับเส้นทาง HTTP และ HTTPS ไฟล์คุณสมบัติอาจมี:

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 จะให้คู่ host และ port ที่เป็นไปได้ คุณสมบัติ bypass HTTPS ก็เป็น http.nonProxyHosts เช่นกัน การคิดค้น https.nonProxyHosts ไม่ใช่วิธีแก้ตามเอกสาร คุณสมบัติ host มีที่อยู่ ไม่ใช่ proxy URL แบบเต็ม

การ export HTTP_PROXY ใน shell ไม่ได้พิสูจน์ด้วยตัวเองว่า JVM client นี้ใช้เป็นนโยบายพร็อกซี ตรวจสอบคุณสมบัติที่แอปพลิเคชันรองรับ

daemon ได้รับข้อมูล build จริง

เอกสาร Gradle ปัจจุบันระบุว่า client ส่งข้อมูล build รวมถึงตัวแปรสภาพแวดล้อมให้ daemon ดังนั้นคำอธิบายกว้าง ๆ ว่า “daemon ไม่เคยได้รับตัวแปรสภาพแวดล้อมใหม่” จึงไม่ถูกต้อง

คุณสมบัติเริ่มต้น JVM บางรายการ รวมถึงคุณสมบัติ trust store เปลี่ยนไม่ได้สำหรับ JVM ที่กำลังทำงาน Java home หรือการตั้งค่าเริ่มต้น trust store ที่เปลี่ยนจึงอาจมีผล แม้ค่าของสภาพแวดล้อม build ปกติจะถูกส่งต่อ

เปรียบเทียบการเปิดใช้งานทั้งสองแบบ

ตรวจสอบว่า IDE เลือก Gradle distribution และ Java runtime ใด ตรวจสอบว่าใช้ GRADLE_USER_HOME และ user properties เดียวกับเทอร์มินัลหรือไม่ รายการพร็อกซีในการตั้งค่าของผู้ใช้คนหนึ่งไม่ได้บอกว่าอีกบริบทโหลดอะไร

หากข้อกำหนดเริ่มต้นที่เปลี่ยนต้องใช้ daemon อื่น ให้ใช้ตัวควบคุม daemon ที่มีเอกสารสำหรับ Gradle รุ่นนั้น อย่าใช้การหยุด daemon แทนการค้นหา property ที่ผิดหรือไฟล์กำหนดค่าที่หายไป

สุดท้ายระบุ request ที่ล้มเหลว การดาวน์โหลด Wrapper การแก้ dependency ของ build และ request จาก process ของแอปหรือการทดสอบที่แยกออกมาไม่ได้อยู่ใน network context เดียวกันโดยอัตโนมัติ ตรวจสอบ process ที่ทำ request ก่อนคาดหวังว่า Gradle property จะควบคุมมัน