Gradle خپل پراکسي تنظیمات له کومه اخلي
د Gradle د JVM پراکسي ځانګړنې، د کارن home تنظیمات او د مراجع چاپېریال تعقیب کړئ؛ داسې مه ګڼئ چې daemon تل نوي بدلونونه له پامه غورځوي.
له IDE څخه پیل شوی Gradle build ښايي له هغه project څخه چې له terminal څخه پیل شوی وي بېل configuration وکاروي. د زړې پراکسي پروسې له ملامتولو مخکې د هر پیل Gradle user home، JVM او proxy properties سره پرتله کړئ.
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 وکاروئ؛ د اجازه لرونکو عامه 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 په توګه کاروي. هغه properties وڅېړئ چې application یې ملاتړ کوي.
Daemon د build معلومات ترلاسه کوي
د Gradle اوسني اسناد وايي چې client د environment variables په ګډون build information 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 غوره کوي. وګورئ چې د terminal په شان هماغه GRADLE_USER_HOME او user properties کاروي که نه. د یوه user په configuration کې proxy entry نه ښيي چې بل context څه load کړي.
که بدله شوې startup requirement بل daemon ته اړتیا لري، د اړوند Gradle version مستند daemon controls وکاروئ. د غلط property یا ورکې configuration file د موندلو پر ځای daemon مه دروئ.
په پای کې ناکامه request وپېژنئ. Wrapper downloads، build dependency resolution او د forked application یا test processes requests په اوتومات ډول یو network context نه دي. مخکې له دې چې د Gradle property د کنټرول تمه وکړئ، request کوونکی process تایید کړئ.