Gradle تنظیمات پراکسی خود را از کجا میگیرد
ویژگیهای پراکسی JVM در Gradle، تنظیمات خانهٔ کاربر و محیط کلاینت را دنبال کنید و فرض نکنید daemon همیشه متغیرهای جدید را نادیده میگیرد.
ساخت Gradle که از یک IDE اجرا میشود ممکن است از پیکربندی متفاوتی نسبت به همان پروژه در ترمینال استفاده کند. پیش از مقصر دانستن فرایند قدیمی پراکسی، خانهٔ کاربر Gradle، 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
از نقطهٔ پایانی اختصاصیافته استفاده کنید؛ برای مسیرهای مجاز به مخازن عمومی، فهرست پراکسی HTTP جفتهای نامزد میزبان و درگاه را ارائه میکند. ویژگی دورزدن HTTPS نیز http.nonProxyHosts است؛ ساختن https.nonProxyHosts راهحل مستندشده نیست. ویژگیهای میزبان شامل نشانی هستند، نه URL کامل پراکسی.
صادر کردن HTTP_PROXY در shell بهتنهایی ثابت نمیکند که این کلاینت JVM آن را بهعنوان سیاست پراکسی استفاده میکند. ویژگیهای پشتیبانیشدهٔ برنامه را بررسی کنید.
daemon واقعاً اطلاعات ساخت را دریافت میکند
مستندات فعلی Gradle میگوید کلاینت اطلاعات ساخت، از جمله متغیرهای محیطی، را برای daemon میفرستد. بنابراین توضیح کلی «daemon هرگز متغیر محیطی جدید دریافت نمیکند» نادرست است.
برخی ویژگیهای راهاندازی JVM، از جمله ویژگیهای مخزن اعتماد، برای JVM در حال اجرا تغییرناپذیرند. در نتیجه تغییر Java home یا پیکربندی راهاندازی مخزن اعتماد میتواند مهم باشد، حتی وقتی مقادیر معمول محیط ساخت منتقل میشوند.
دو اجرا را مقایسه کنید
بررسی کنید IDE کدام توزیع Gradle و زماناجرای Java را انتخاب میکند. بررسی کنید آیا همان GRADLE_USER_HOME و ویژگیهای کاربر ترمینال را به کار میبرد. وجود ورودی پراکسی در پیکربندی یک کاربر نشان نمیدهد زمینهٔ دیگر چه چیزی بارگذاری کرده است.
اگر نیاز راهاندازی تغییرکرده به daemon دیگری نیاز دارد، کنترلهای مستند daemon را برای نسخهٔ مربوط Gradle به کار ببرید. متوقف کردن daemonها را جایگزین یافتن ویژگی نادرست یا فایل پیکربندی گمشده نکنید.
در پایان، درخواست ناموفق را مشخص کنید. بارگیریهای Wrapper، حل وابستگیهای ساخت و درخواستهای فرایندهای منشعب برنامه یا آزمون خودبهخود یک زمینهٔ شبکهای نیستند. پیش از انتظار برای کنترل آن توسط ویژگی Gradle، فرایند درخواستکننده را بررسی کنید.