Gradle ទទួលការកំណត់ប្រូកស៊ីពីណា

តាមដានលក្ខណៈប្រូកស៊ី JVM របស់ Gradle ការកំណត់ home របស់អ្នកប្រើ និងបរិស្ថានម៉ាស៊ីនភ្ញៀវ កុំសន្មតថា daemon តែងតែមិនអើពើអថេរថ្មី។

Gradle build ដែលចាប់ផ្ដើមពី IDE អាចប្រើការកំណត់ខុសពីគម្រោងដដែលដែលចាប់ផ្ដើមពី terminal។ មុនបន្ទោសដំណើរការប្រូកស៊ីចាស់ សូមប្រៀបធៀប 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 ពេញលេញទេ។

ការនាំចេញ HTTP_PROXY ក្នុង shell មិនបញ្ជាក់ដោយខ្លួនឯងថា JVM client នេះប្រើវាជាគោលការណ៍ប្រូកស៊ីទេ។ ពិនិត្យលក្ខណៈដែលកម្មវិធីគាំទ្រ។

Daemon ទទួលព័ត៌មាន build

ឯកសារ Gradle បច្ចុប្បន្ននិយាយថា client ផ្ញើ build information រួមទាំង environment variables ទៅ daemon។ ដូច្នេះការពន្យល់ទូទៅថា “daemon មិនដែលទទួល environment variables ថ្មី” មិនត្រឹមត្រូវទេ។

លក្ខណៈចាប់ផ្ដើម JVM មួយចំនួន រួមទាំង trust-store properties មិនអាចប្ដូរបានសម្រាប់ JVM ដែលកំពុងដំណើរការ។ ដូច្នេះ Java home ឬ trust-store startup configuration ដែលបានប្ដូរអាចសំខាន់ ទោះតម្លៃបរិស្ថាន build ធម្មតាត្រូវបានបញ្ជូនក៏ដោយ។

ប្រៀបធៀបការចាប់ផ្ដើមទាំងពីរ

ពិនិត្យ Gradle distribution និង Java runtime ដែល IDE ជ្រើស។ ពិនិត្យថាវាប្រើ GRADLE_USER_HOME និង user properties ដូច terminal ឬទេ។ Proxy entry ក្នុង configuration របស់អ្នកប្រើម្នាក់ មិនបង្ហាញថា context មួយទៀតបានផ្ទុកអ្វីទេ។

បើ startup requirement ដែលប្ដូរត្រូវការ daemon ផ្សេង ប្រើ documented daemon controls សម្រាប់ Gradle version នោះ។ កុំចាត់ទុកការបញ្ឈប់ daemon ជំនួសឱ្យការស្វែងរក property ខុស ឬ configuration file ដែលបាត់។

ចុងក្រោយ កំណត់ request ដែលបរាជ័យ។ Wrapper downloads, build dependency resolution និង requests ពី forked application/test processes មិនមែនជាបណ្តាញ context តែមួយដោយស្វ័យប្រវត្តិទេ។ ផ្ទៀងផ្ទាត់ process ដែលធ្វើ request មុនរំពឹងថា Gradle property នឹងគ្រប់គ្រងវា។

អត្ថបទពាក់ព័ន្ធ