Gradle কোথা থেকে তার প্রক্সি সেটিং পায়
Gradle-এর JVM প্রক্সি প্রপার্টি, ব্যবহারকারীর হোম সেটিং এবং ক্লায়েন্ট পরিবেশ অনুসরণ করুন; daemon সবসময় নতুন ভেরিয়েবল উপেক্ষা করে এমন ধরে নেবেন না।
IDE থেকে চালানো Gradle build টার্মিনাল থেকে চালানো একই প্রকল্পের চেয়ে আলাদা কনফিগারেশন ব্যবহার করতে পারে। পুরোনো প্রক্সি প্রসেসকে দোষ দেওয়ার আগে প্রতিটি চালুর Gradle user home, JVM এবং প্রক্সি প্রপার্টি তুলনা করুন।
Gradle JVM প্রক্সি প্রপার্টি নথিভুক্ত করে
HTTP ও HTTPS রুটের জন্য properties ফাইলে থাকতে পারে:
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 property-তে ঠিকানা থাকে, সম্পূর্ণ proxy URL নয়।
Shell-এ HTTP_PROXY export করলেই এই JVM client সেটিকে proxy policy হিসেবে ব্যবহার করছে প্রমাণ হয় না। অ্যাপ্লিকেশন যে property সমর্থন করে তা পরীক্ষা করুন।
Daemon build-এর তথ্য পায়
বর্তমান Gradle documentation বলে client environment variable-সহ build information daemon-কে পাঠায়। তাই “daemon কখনও নতুন environment variable পায় না” সাধারণ ব্যাখ্যাটি সঠিক নয়।
কিছু JVM startup property, যার মধ্যে trust-store property-ও আছে, চলমান JVM-এর জন্য অপরিবর্তনীয়। তাই সাধারণ build environment value পাঠানো হলেও বদলানো Java home বা trust-store startup configuration গুরুত্বপূর্ণ হতে পারে।
দুটি চালনা তুলনা করুন
IDE কোন Gradle distribution ও Java runtime বেছে নেয় তা দেখুন। এটি টার্মিনালের মতো একই GRADLE_USER_HOME ও user property ব্যবহার করে কি না দেখুন। একজন ব্যবহারকারীর configuration-এ proxy entry থাকলেই অন্য context কী load করেছে তা জানা যায় না।
বদলানো startup requirement-এর জন্য আলাদা daemon দরকার হলে সংশ্লিষ্ট Gradle version-এর documented daemon control ব্যবহার করুন। ভুল property বা অনুপস্থিত configuration file খোঁজার বদলে daemon বন্ধ করবেন না।
শেষে কোন request ব্যর্থ হয়েছে শনাক্ত করুন। Wrapper download, build dependency resolution এবং forked application বা test process-এর request স্বয়ংক্রিয়ভাবে একই network context নয়। Gradle property তা নিয়ন্ত্রণ করবে ধরে নেওয়ার আগে request করা process যাচাই করুন।