আপনার বিল্ড সংজ্ঞা কোনো কাজে লাগার মতো কিছু করার আগেই sbt-এর নেটওয়ার্ক প্রয়োজন হতে পারে। এর লঞ্চারকে উপাদান সংগ্রহ করতে হয়, আর বিল্ড পরে অতিরিক্ত লাইব্রেরির মাধ্যমে রিপোজিটরির সঙ্গে যোগাযোগ করতে পারে। কোনো টাস্কের ভেতরে লুকানো প্রক্সি সেটিং প্রথম ডাউনলোডের জন্য অনেক দেরিতে আসতে পারে।

যে JVM আসলে sbt চালায়, সেখান থেকেই শুরু করুন। যে লঞ্চার প্রকল্পের .jvmopts পড়ে, তার জন্য মৌলিক এন্ডপয়েন্ট বৈশিষ্ট্য হতে পারে:

-Dhttp.proxyHost=proxy.example.net
-Dhttp.proxyPort=8080
-Dhttps.proxyHost=proxy.example.net
-Dhttps.proxyPort=8080

এই মানগুলি হোস্টনেম ও পোর্ট আলাদা করে; এগুলি সম্পূর্ণ প্রক্সি URL নয়। অনুমোদিত পাবলিক রিপোজিটরি ডাউনলোডের জন্য HTTP প্রক্সি তালিকা ওই ক্ষেত্রগুলির জন্য সম্ভাব্য মান যোগায়। HTTPS রিপোজিটরিতেও CONNECT ব্যবহার করে HTTP প্রক্সির মাধ্যমে পৌঁছানো যায়।

কোন ডাউনলোডটি ব্যর্থ হয়েছে লক্ষ্য করুন

লঞ্চার বুটস্ট্র্যাপ, বিল্ড-টুল উপাদান, প্লাগইন ও নির্ভরতাগুলি সবসময় একই কনফিগারেশন স্তর ব্যবহার করে না। রিপোজিটরি ঘোষণা সম্পাদনার আগে ব্যর্থ URL ও ধাপটি চিহ্নিত করুন।

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

প্রক্সি প্রমাণীকরণ আরেকটি পরীক্ষা। প্রতিটি Java ডাউনলোডার যে কোনো proxyUser বৈশিষ্ট্যকে সমর্থিত লগইন ব্যবস্থা হিসেবে গণ্য করে ধরে নেবেন না। ইনস্টল করা লঞ্চার ও সংশ্লিষ্ট রিজলভারের জন্য নথিভুক্ত প্রমাণীকরণ ব্যবস্থা ব্যবহার করুন।

শেষে, অন্য রানারের জন্য লেখা গাইড থেকে ভেরিয়েবল কপি না করে কার্যকর লঞ্চার পরিবেশ পরীক্ষা করুন। DNS ব্যর্থতা, অনুপলব্ধ রিপোজিটরি ও প্রত্যাখ্যাত প্রক্সি লগইন—সবই নির্ভরতা সমাধানের সময় দেখা দিতে পারে, অথচ এদের জন্য খুব আলাদা সমাধান দরকার।

সম্পর্কিত নিবন্ধ