Maven-কে proxy প্লাগইন চালানোর আগে সেটিতে পৌঁছাতে হবে

স্বয়ংক্রিয় proxy প্লাগইন নেটওয়ার্কের মধ্যে চলাচল করা ল্যাপটপের জন্য আদর্শ শোনায়। তবে একটি অস্বস্তিকর প্রথম অনুরোধ আছে: Maven-এর প্লাগইনটি নিজেই পেতে proxy প্রয়োজন হতে পারে।

প্লাগইন লক্ষ্য কেবল তখনই চলে যখন Maven তার বাস্তবায়ন ও প্রয়োজনীয় আর্টিফ্যাক্ট সমাধান ও লোড করতে পারে। সেই বাস্তবায়নের ভিতরে proxy আবিষ্কার এমন ডাউনলোডে সাহায্য করতে পারে না যা বাস্তবায়ন শুরুর আগেই ব্যর্থ হয়। সম্পূর্ণ যোগ্য প্লাগইন কোঅর্ডিনেট ব্যবহার করলে প্রিফিক্স অনুসন্ধান এড়ানো যায়; তবে খালি স্থানীয় ভাণ্ডারে প্লাগইন আর্টিফ্যাক্ট তৈরি করে না।

পুরনো Autoproxy Maven প্লাগইন এই পার্থক্য দেখায়। এর README proxy-vole-এর মাধ্যমে proxy আবিষ্কার বর্ণনা করে, তবে লক্ষ্য আহ্বানের আগে প্লাগইনটি স্থানীয়ভাবে ইনস্টল করারও বর্ণনা করে। এটিকে সেই নির্দিষ্ট ডিজাইনের পূর্বশর্ত হিসেবে দেখুন, Maven সার্বজনীনভাবে ব্রাউজারের PAC সেটিংস পড়ে তার প্রমাণ হিসেবে নয়।

প্রথম সমাধানকে একটি স্পষ্ট পথ দিন

যে নেটওয়ার্কে ভাণ্ডার অ্যাক্সেসের জন্য HTTP proxy প্রয়োজন, সেই আহ্বানে ব্যবহৃত Maven সেটিংসে উপযুক্ত সক্রিয় proxy কনফিগার করুন। অনুমোদিত পাবলিক-ভাণ্ডার বুটস্ট্র্যাপের জন্য HTTP proxy তালিকা থেকে একটি HTTP প্রার্থী বাছুন। বাহ্যিক পথ ছাড়াই পৌঁছানো যায় এমন অনুমোদিত অভ্যন্তরীণ ভাণ্ডারও প্রাথমিক অ্যাক্সেস সমস্যা সমাধান করতে পারে। যেকোনো পদ্ধতিকে প্লাগইন ও তার নির্ভরতাগুলি কভার করতে হবে, কেবল অ্যাপ্লিকেশনের নির্ভরতা নয়।

আগে ভরা স্থানীয় ভাণ্ডার বুটস্ট্র্যাপ প্রয়োজনীয়তা লুকাতে পারে। ডেভেলপারের ল্যাপটপে সাফল্য প্রমাণ করে না যে নতুন CI অ্যাকাউন্ট একই বিল্ড শুরু করতে পারে। প্লাগইনের সনাক্তকরণ লজিক বদলানোর আগে ব্যর্থ আর্টিফ্যাক্ট ও পর্যায় দেখুন।

প্লাগইন লোড হওয়ার পরে, পরবর্তী নির্ভরতা ব্যর্থতা আলাদা প্রশ্ন হয়ে ওঠে: এর সনাক্ত করা পথ সঠিক কি না এবং সক্রিয় Maven পরিবহন ফলস্বরূপ সেটিংস ব্যবহার করে কি না। স্বয়ংক্রিয় সনাক্তকরণ রাখা মূল্যবান কি না নির্ধারণ করার সময় সেই দুটি ব্যর্থতার বিন্দু আলাদা রাখুন।