Gradle ले प्रोक्सी सेटिङ कहाँबाट लिन्छ

IDE बाट सुरु गरिएको Gradle build ले टर्मिनलबाट सुरु गरिएको त्यही परियोजनाभन्दा फरक कन्फिगरेसन प्रयोग गर्न सक्छ। पुरानो प्रोक्सी प्रक्रियालाई दोष दिनुअघि प्रत्येक सुरुवातको 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 प्रयोग गर्नुहोस्; अनुमति भएका सार्वजनिक 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 का रूपमा प्रयोग गर्छ भन्ने प्रमाण हुँदैन। एप्लिकेसनले समर्थन गर्ने property जाँच्नुहोस्।

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 रोज्छ जाँच्नुहोस्। टर्मिनलजस्तै 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 process का requests स्वतः एउटै network context होइनन्। Gradle property ले नियन्त्रण गर्छ भन्ने अपेक्षा गर्नुअघि request गर्ने process जाँच्नुहोस्।