Gradle သည် ပရောက်စီဆက်တင်များကို မည်သည့်နေရာမှ ရယူသနည်း

IDE မှ စတင်သည့် Gradle build သည် terminal မှ စတင်သည့် project တစ်ခုတည်းထက် မတူညီသော configuration ကို အသုံးပြုနိုင်သည်။ ပရောက်စီ process အဟောင်းကို အပြစ်မတင်မီ စတင်မှုတိုင်း၏ Gradle user home၊ JVM နှင့် ပရောက်စီဂုဏ်သတ္တိများကို နှိုင်းယှဉ်ပါ။

Gradle သည် JVM ပရောက်စီဂုဏ်သတ္တိများကို မှတ်တမ်းတင်ထားသည်

HTTP နှင့် HTTPS လမ်းကြောင်းများအတွက် properties file တွင် အောက်ပါအရာများ ပါနိုင်သည်။

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 list သည် host နှင့် port အတွဲများကို ပေးသည်။ HTTPS bypass property သည်လည်း http.nonProxyHosts ဖြစ်သည်။ https.nonProxyHosts ကို တီထွင်ခြင်းသည် မှတ်တမ်းတင်ထားသော ဖြေရှင်းချက်မဟုတ်ပါ။ Host properties တွင် proxy URL အပြည့်မဟုတ်ဘဲ လိပ်စာပါသည်။

Shell တွင် HTTP_PROXY ကို export လုပ်ခြင်းက ဤ JVM client သည် ၎င်းကို proxy policy အဖြစ် သုံးနေကြောင်း တစ်ခုတည်းဖြင့် သက်သေမပြပါ။ Application က ပံ့ပိုးသည့် properties များကို စစ်ဆေးပါ။

Daemon သည် build အချက်အလက်ကို လက်ခံသည်

လက်ရှိ Gradle documentation အရ client သည် environment variables အပါအဝင် build information ကို daemon သို့ ပို့သည်။ ထို့ကြောင့် “daemon သည် environment variables အသစ်ကို ဘယ်တော့မှ မရ” ဟူသော အထွေထွေရှင်းလင်းချက်သည် မမှန်ကန်ပါ။

Trust-store properties အပါအဝင် JVM startup properties အချို့သည် လည်ပတ်နေသော JVM အတွက် ပြောင်းလဲ၍ မရပါ။ ထို့ကြောင့် ပုံမှန် build environment values များကို ပို့ပေးနေသော်လည်း Java home သို့မဟုတ် trust-store startup configuration ပြောင်းလဲမှုသည် အရေးပါနိုင်သည်။

စတင်မှုနှစ်ခုကို နှိုင်းယှဉ်ပါ

IDE က ရွေးချယ်သည့် Gradle distribution နှင့် Java runtime ကို စစ်ဆေးပါ။ Terminal ကဲ့သို့ GRADLE_USER_HOME နှင့် user properties များကို အသုံးပြုခြင်း ရှိမရှိ စစ်ဆေးပါ။ User တစ်ဦး၏ configuration ရှိ proxy entry တစ်ခုက အခြား context က ဘာကို load လုပ်ခဲ့သည်ကို မပြပါ။

ပြောင်းလဲထားသော startup requirement က daemon အခြားတစ်ခု လိုအပ်လျှင် သက်ဆိုင်ရာ Gradle version ၏ documented daemon controls ကို သုံးပါ။ မှားယွင်းသော property သို့မဟုတ် ပျောက်ဆုံးနေသော configuration file ကို ရှာရန် daemon ကို ရပ်တန့်ခြင်းကို အစားထိုးမလုပ်ပါနှင့်။

နောက်ဆုံး မအောင်မြင်သော request ကို သတ်မှတ်ပါ။ Wrapper downloads၊ build dependency resolution နှင့် forked application/test processes များ၏ requests များသည် အလိုအလျောက် network context တစ်ခုတည်း မဟုတ်ပါ။ Gradle property က ထိန်းချုပ်မည်ဟု မမျှော်လင့်မီ request ပြုလုပ်သည့် process ကို အတည်ပြုပါ။