পরীক্ষার HTTP অনুরোধের জন্য Maven Surefire প্রক্সি সেটিংস
Maven-এর রিপোজিটরি প্রক্সি টেস্ট JVM-এর ভিতরে যেকোনো HTTP ক্লায়েন্ট কনফিগার করে না। টেস্ট যে অনুরোধ করে তা অনুসরণ করে কনফিগার করুন।
Maven-এর রিপোজিটরি প্রক্সি একটি টেস্টের করা HTTP অনুরোধ কনফিগার না করেই নির্ভরতা আনতে পারে। ক্লায়েন্টটি টেস্ট JVM-এ কনফিগার করুন।
যদি সেই ক্লায়েন্ট Java-এর HTTPS প্রক্সি প্রপার্টি মানে, তবে এই অংশটি সংস্লিষ্ট Surefire প্লাগইনের configuration এলিমেন্টের ভিতরে রাখুন:
<systemPropertyVariables>
<https.proxyHost>proxy.example</https.proxyHost>
<https.proxyPort>8080</https.proxyPort>
</systemPropertyVariables>উদাহরণ এন্ডপয়়েন্টটি বদলান। পাবলিক গন্তব্যের বিরুদ্ধে টেস্টের জন্য, যেখানে পাবলিক মধ্যস্থতাকারী অনুমোদিত, HTTP প্রক্সি তালিকা হোস্ট ও পোর্টের প্রার্থী দেয়। হোস্ট ও পোর্ট আলাদা মান; গন্তব্যের স্কিম ও লাইব্রেরির সাথে মানানসই প্রপার্টি পরিবার বেছে নিন। আর স্পষ্ট প্রক্সি অবজেক্ট দিয়ে তৈরি ক্লায়েন্টের বরং নিজস্ব কনফিগারেশন ইন্টারফেস দরকার।
Surefire সাধারণত ফর্ক করা JVM-এ টেস্ট চালায়। Maven চালু করার প্রতিটি অপশন সেই প্রসেসে পৌঁছায় না। স্টার্টআপ-সংবেদনশীল সিস্টেম-প্রক্সি আবিষ্কার-এর অপশনটি চালুর সময় টেস্ট JVM-এ থাকা দরকার। টেস্ট একটি প্রসেস ভাগ করলেও একটি লাইব্রেরি Java-এর ডিফল্ট প্রক্সি প্রপার্টি উপেক্ষা করতে পারে।
ভিতরের সরাসরি গন্তব্য উপযুক্ত বাইপাস নিয়মে ঢেকে রাখুন, প্রক্সি প্রমাণীকরণ গন্তব্য প্রমাণীকরণ থেকে আলাদা রাখুন এবং সার্টিফিকেট যাচাই সক্রিয় রাখুন। ফর্কিং বন্ধ করলে টেস্ট কীভাবে চলে তা বদলায়; নির্ভরতা মিরর বদলালে রিপোজিটরি সমাধান বদলায়। কোনটিই অনুপস্থিত টেস্ট-ক্লায়েন্ট পথ দেয় না। সব সিস্টেম প্রপার্টি কপি করলে গোপন তথ্যও প্রকাশ হতে পারে।
বাকি থাকা ব্যর্থতার জন্য টেস্ট JVM, HTTP লাইব্রেরি, লক্ষ্য, নির্বাচিত প্রক্সি এবং প্রথম ব্যর্থ পর্যায় লিখে রাখুন। এই পর্যবেক্ষণগুলো টেস্ট কনফিগারেশনের দিকে ইংগিত করে, কাজ করা রিপোজিটরি ডাউনলোডগুলো বোঝার মতো থাকে।