গ্রেডল কি সত্যিই মাভেনের চেয়ে ভাল? - আমার চূড়ান্ত রায়

আমি প্রযুক্তিগত বিষয়বস্তু টুইট করি যেগুলিকে আমি আকর্ষণীয় মনে করি, কিন্তু মজার টুইটগুলিই সবচেয়ে বেশি ব্যস্ততা পায়৷ আমি মার্চ মাসে জাভাল্যান্ড কনফারেন্সে যোগ দিয়েছিলাম, গ্রেডল বুথে হোঁচট খেয়েছিলাম এবং এই রত্নটি খুঁজে পেয়েছি:

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

এটি পরিচালনা করতে, আমাকে সময়মতো ফিরে যেতে হবে। সফ্টওয়্যার বিকাশ একটি দ্রুত পরিবর্তনশীল ক্ষেত্র, এবং আমাদের বোঝার বেশিরভাগ ব্যক্তিগত অভিজ্ঞতার উপর ভিত্তি করে। তাই এখানে আমার.

আমার প্রথম বিল্ড টুল: পিঁপড়া

আমি 2002 সালে জাভাতে বিকাশ শুরু করি। সেই সময়ে, কোন বিল্ড টুল ছিল না: আমরা IDE এর মাধ্যমে কম্পাইল এবং তৈরি করেছি। রেকর্ডের জন্য, আমি প্রথম জাভার জন্য ভিজ্যুয়াল এজ ব্যবহার করেছি; তারপর, আমি বোরল্যান্ড জেবিল্ডারে চলে যাই।

একটি IDE এর সাথে বিল্ডিং একটি বিশাল সমস্যা আছে: প্রতিটি ডেভেলপারের ডেডিকেটেড সেটিংস আছে, তাই আর্টিফ্যাক্ট জেনারেশন ডেভেলপার-মেশিনের সমন্বয়ের উপর নির্ভর করে।

অ-পুনরাবৃত্তিযোগ্য বিল্ড একটি পুরানো সমস্যা। পুনরাবৃত্তিযোগ্য বিল্ডগুলির সাথে আমার প্রথম অভিজ্ঞতা হল অ্যাপাচি অ্যান্ট:

Apache Ant হল একটি জাভা লাইব্রেরি এবং কমান্ড-লাইন টুল যার লক্ষ্য হল বিল্ড ফাইলগুলিতে বর্ণিত প্রসেসগুলিকে একে অপরের উপর নির্ভরশীল লক্ষ্য এবং এক্সটেনশন পয়েন্ট হিসাবে চালনা করা। অ্যান্টের প্রধান পরিচিত ব্যবহার হল জাভা অ্যাপ্লিকেশন তৈরি করা। পিঁপড়া জাভা অ্যাপ্লিকেশনগুলিকে কম্পাইল, একত্রিত, পরীক্ষা এবং চালানোর অনুমতি দেয় এমন অনেকগুলি অন্তর্নির্মিত কাজ সরবরাহ করে। নন-জাভা অ্যাপ্লিকেশনগুলি তৈরি করতেও পিঁপড়া কার্যকরভাবে ব্যবহার করা যেতে পারে, উদাহরণস্বরূপ C বা C++ অ্যাপ্লিকেশন। আরও সাধারণভাবে, পিঁপড়াকে লক্ষ্য ও কার্যের পরিপ্রেক্ষিতে বর্ণনা করা যেতে পারে এমন যেকোনো প্রক্রিয়ার পাইলট করতে ব্যবহার করা যেতে পারে।

-- https://ant.apache.org/

পিঁপড়া তিনটি প্রধান বিমূর্ততার উপর ভিত্তি করে:

• একটি টাস্ক হল কাজের একটি পারমাণবিক একক, যেমন , জাভা ফাইল কম্পাইল করার জন্য javac , একটি ওয়েব আর্কাইভ একত্রিত করার war ইত্যাদি। পিঁপড়া অনেকগুলি কাজকে বাক্সের বাইরে দেয় কিন্তু কাস্টম যুক্ত করার অনুমতি দেয়।
• টার্গেট হল কাজের একটি তালিকা।
• আপনি কাজগুলির মধ্যে নির্ভরতা সংজ্ঞায়িত করতে পারেন, যেমন কম্পাইলের উপর নির্ভর করে প্যাকেজ । এই বিষয়ে, আপনি একটি ওয়ার্কফ্লো এক্সিকিউশন ইঞ্জিন হিসাবে পিঁপড়া দেখতে পারেন।

আমি শীঘ্রই পিঁপড়াতে "সাবলীল" হয়ে উঠলাম। একজন পরামর্শদাতা হিসাবে, আমি কোম্পানি থেকে কোম্পানি, প্রকল্প থেকে প্রকল্পে গিয়েছিলাম। প্রাথমিকভাবে, আমি বেশিরভাগই পিঁপড়া সেট আপ করি, কিন্তু পিপীলিকা সময়ের সাথে সাথে আরও ব্যাপক হয়ে ওঠে এবং আমি বিদ্যমান অ্যান্ট সেটআপগুলির সম্মুখীন হয়েছিলাম। আমি আমার প্রকল্পগুলিতে সামঞ্জস্যপূর্ণ ছিলাম, তবে অন্যান্য প্রকল্পগুলি একে অপরের থেকে খুব আলাদা ছিল।

প্রতিবার, একটি নতুন প্রকল্পে আসার সময়, আপনাকে কাস্টম বিল্ড বোঝার জন্য পিঁপড়ার সেট আপ সাবধানে পড়তে হয়েছিল। তদুপরি, প্রতিটি প্রকল্পের কাঠামো আলাদা ছিল। কেউ তাদের সোর্স src , কেউ sources , কেউ নেস্টেড স্ট্রাকচার ইত্যাদিতে রাখে।

আমার মনে আছে একবার একটি জেনেরিক বিল্ড ফাইল যা একটি প্রতিষ্ঠানের পুরো প্রকল্পের প্রয়োজন মিটমাট করার চেষ্টা করেছিল। এটি XML এর 2,000 টিরও বেশি লাইনে 80 টিরও বেশি লক্ষ্যকে সংজ্ঞায়িত করেছে। সাহায্যের সাথে কীভাবে এটি ব্যবহার করতে হয় তা বুঝতে আমার একটি অ-তুচ্ছ পরিমাণ সময় লেগেছে এবং প্রকল্পগুলি না ভেঙে এটিকে টুইক করতে সক্ষম হতে আরও বেশি সময় লেগেছে।

আমার দ্বিতীয় বিল্ড টুল: Maven

উপরের প্রকল্পটি আমাকে অনেক ভাবিয়েছে। আমি পরিস্থিতির উন্নতি করতে চেয়েছিলাম কারণ রক্ষণাবেক্ষণকারীরা ইতিমধ্যেই পিঁপড়ার সীমা ঠেলে দিয়েছে। সেই সময়, আমি আমার বন্ধু ফ্রেডি ম্যালেট (সোনার খ্যাত) এর সাথে কাজ করছিলাম। আমরা কথা বললাম, এবং তিনি আমাকে ম্যাভেনের দিকে ইঙ্গিত করলেন। আমি একবার মাভেনের সাথে একটি প্রকল্প তৈরি করেছি কিন্তু অন্য কোন পূর্ব অভিজ্ঞতা ছিল না। আমি ঘন্টার পর ঘন্টা ডকুমেন্টেশন অধ্যয়ন করেছি, এবং ফ্রেডির তত্ত্বাবধানে ট্রায়াল-এন্ড-এরর প্রচেষ্টার মাধ্যমে, পুরো পিঁপড়া বিল্ড ফাইলটিকে একটি সাধারণ প্যারেন্ট POM-এ স্থানান্তরিত করেছি।

পিঁপড়ে, আপনাকে প্রতিটি প্রকল্পে সবকিছু সংজ্ঞায়িত করতে হবে। উদাহরণস্বরূপ, পিঁপড়ার সংকলনের জন্য জাভা ফাইলের অবস্থান কনফিগার করা প্রয়োজন; Maven অনুমান করে যে তারা src/main/java অধীনে রয়েছে, যদিও এটি ওভাররাইড করা সম্ভব। ম্যাভেন কনভেনশন ওভার কনফিগারেশন পদ্ধতির মাধ্যমে জাভা বিল্ড ফিল্ডে বিপ্লব ঘটিয়েছে। আজকাল, প্রচুর সফ্টওয়্যার ডিফল্টরূপে সংবেদনশীল কনফিগারেশন অফার করে।

ডেভেলপারদের জন্য যারা প্রজেক্ট থেকে প্রোজেক্টে যায়, যেমনটা আমি করেছি, এর মানে হল একটি নতুন প্রোজেক্টে যোগদান করার সময় অনেক কম জ্ঞানীয় লোড থাকে। আমি আশা করি জাভা উত্সগুলি src/main/java অধীনে অবস্থিত হবে। মাভেন কনভেনশনগুলি প্রকল্পের কাঠামোর বাইরে চলতে থাকে। তারা প্রকল্পের জীবনচক্র সংজ্ঞায়িত করে, সংকলন থেকে শুরু করে একটি দূরবর্তী রেজিস্ট্রিতে আর্টিফ্যাক্ট আপলোড করা পর্যন্ত, ইউনিট এবং ইন্টিগ্রেশন পরীক্ষার মাধ্যমে।

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

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

অপরিবর্তনীয়তার জন্য অনেক।

মাভেনের পরবর্তী সমস্ত নির্মাণ সরঞ্জামগুলিতে গভীর প্রভাব ছিল: তারা মাভেনের রেফারেন্সে নিজেদেরকে সংজ্ঞায়িত করেছিল।

আমার কোন বিল্ড টুল: Gradle

গ্রেডলের প্রাথমিক দাবি ছিল ম্যাভেনের ত্রুটিগুলি ঠিক করা, বা কমপক্ষে যা এটি অনুভূত হয়েছিল। যদিও মাভেন তিরস্কারের হাত থেকে রেহাই পায়নি, গ্র্যাডল ধরে নিয়েছিল সবচেয়ে উল্লেখযোগ্য সমস্যা হল এর নমনীয়তার অভাব। এটি একটি আশ্চর্যজনক অনুমান কারণ ম্যাভেন পিঁপড়ার চেয়ে ঠিক এটিই উন্নত করেছিল। মাভেন প্রকল্পগুলির একই কাঠামো রয়েছে এবং একই জীবনচক্র ব্যবহার করে: প্রভাবে অন্তত বিস্ময়ের নীতি । বিপরীতভাবে, Gradle জীবনচক্র সহ প্রায় প্রতিটি বিল্ড দিক কাস্টমাইজ করার অনুমতি দেয়।

নমনীয়তার যুক্তির মুখোমুখি হওয়ার আগে, আমাকে দুটি দুর্দান্ত মূল গ্রেডল বৈশিষ্ট্য স্বীকার করতে দিন যা ম্যাভেন পরে প্রয়োগ করেছিল: গ্রেডল ডেমন এবং গ্রেডল র্যাপার।

Maven এবং Gradle উভয়ই জাভা অ্যাপ্লিকেশন যা JVM এ চলে। একটি JVM শুরু করা সময় এবং সম্পদের পরিপ্রেক্ষিতে ব্যয়বহুল। সুবিধা হল যে দীর্ঘমেয়াদী JVM সময়ের সাথে JIT-ed কোডকে অপ্টিমাইজ করবে। স্বল্প-মেয়াদী কাজের জন্য, সুবিধা শূন্য এবং এমনকি ক্ষতিকর যদি আপনি JVM শুরুর সময়কে বিবেচনায় নেন। Gradle Gradle ডেমন নিয়ে এসেছিল। আপনি যখন Gradle চালান, এটি একটি চলমান ডেমনের সন্ধান করবে। যদি না হয়, এটি একটি নতুন শুরু হবে। কমান্ড-লাইন অ্যাপটি ডেমনে সবকিছু অর্পণ করবে। এর নাম থেকে বোঝা যায়, কমান্ড লাইন শেষ হয়ে গেলে ডেমন থামে না। ডেমন JVM-এর সুবিধাগুলি লাভ করে।

সম্ভাবনা হল যে আপনার অ্যাপ্লিকেশনটি আপনার বর্তমান বিল্ড সরঞ্জামগুলিকে ছাড়িয়ে যাবে। এখন থেকে পাঁচ বছর আগে যখন আপনাকে একটি বাগ ঠিক করতে হবে তখন কী হবে, শুধুমাত্র লক্ষ্য করার জন্য যে প্রকল্পের বিল্ড টুল অনলাইনে উপলব্ধ নয়? Gradle এর র‍্যাপারের পিছনে ধারণাটি হল প্রকল্পের সাথে সঠিক Gradle সংস্করণটি রাখা এবং ইন্টারনেটে সম্পূর্ণ সংস্করণ ডাউনলোড করার জন্য যথেষ্ট কোড। একটি পার্শ্ব-প্রতিক্রিয়া হিসাবে, ডেভেলপারদের স্থানীয়ভাবে Gradle ইনস্টল করার প্রয়োজন নেই; সকলে একই সংস্করণ ব্যবহার করে, কোনো অসঙ্গতি এড়িয়ে।

Gradle এর নমনীয়তা debunking

গ্রেডল উপরে দুটি দুর্দান্ত বৈশিষ্ট্য এনেছে যা ম্যাভেন একত্রিত করেছে, প্রমাণ করে যে প্রতিযোগিতা ভাল। এই সত্ত্বেও, আমি এখনও Gradle এর কোন সুবিধা খুঁজে পাই না।

আমি মানসিক দিকটি দূরে ঠেলে দেওয়ার চেষ্টা করব। এর শুরুতে, গ্রেডল মার্কেটিং প্রতিটি সম্ভাব্য উপলক্ষ্যে মাভেনকে নামিয়ে দেওয়ার চেষ্টা করেছিল, পাগল তুলনা চার্ট প্রকাশ করেছিল এবং সাধারণত এটির যোগাযোগের ক্ষেত্রে খুব আক্রমণাত্মক ছিল। ধরা যাক যে এই পর্যায়টি বাজারে তার জায়গা খোঁজার চেষ্টা করা একটি তরুণ কোম্পানির জন্য গ্রহণযোগ্য হওয়ার চেয়ে অনেক বেশি স্থায়ী হয়েছিল। আপনি বলতে পারেন যে গ্রেডল তার পদ্ধতিতে খুব ইডিপিয়ান ছিল: তার মাভেন "পিতাকে হত্যা করার চেষ্টা করছে।" অবশেষে, এই সমস্ত বছর পরে, মনে হচ্ছে এটি বুদ্ধিমান হয়েছে এবং এখন "মাভেনকে ভালবাসে।"

মনে রাখবেন যে ম্যাভেন দায়িত্ব নেওয়ার আগে, প্রতিটি অ্যান্ট প্রকল্প অ্যাডহক ছিল। মাভেন এর অবসান ঘটিয়েছেন। এটি কাস্টম প্রকল্পের ওয়ার্ল্ড ওয়াইল্ড ওয়েস্টে আইন এনেছে। আপনি আইনের সাথে দ্বিমত পোষণ করতে পারেন, তবে এটি যেভাবেই হোক আইন, এবং প্রত্যেকেরই এর পাশে দাঁড়াতে হবে। মাভেন স্ট্যান্ডার্ডগুলি এতটাই আবদ্ধ যে যদিও কিছু পরামিতি ওভাররাইড করা সম্ভব, যেমন , উৎসের অবস্থান, কেউ কখনও তা করে না।

আমি গ্রেডলের নমনীয়তার দুটি লক্ষণ অনুভব করেছি। আমি আরও অনেক বেশি অস্তিত্ব সন্দেহ.

কাস্টম জীবনচক্র পর্যায়ক্রমে

ম্যাভেন চারটি ধাপে ইন্টিগ্রেশন টেস্টিং পরিচালনা করে, ক্রমানুসারে চালান:

1. pre-integration-test : পরীক্ষার জন্য প্রয়োজনীয় কিছু সেট আপ করুন
2. integration-test : পরীক্ষা চালান
3. post-integration-test : সম্পদ পরিষ্কার করুন, যদি থাকে
4. verify : পরীক্ষার ফলাফলের উপর কাজ করুন

আমি কখনই প্রাক- এবং পরবর্তী পর্যায়গুলি ব্যবহার করিনি, কারণ প্রতিটি পরীক্ষার একটি ডেডিকেটেড সেটআপ এবং টিয়ারডাউন যুক্তি ছিল।

অন্যদিকে, গ্রেডলের ইন্টিগ্রেশন পরীক্ষার কোন ধারণা নেই । তবুও, গ্রেডল ফ্যানবয়রা আনন্দের সাথে ব্যাখ্যা করবে যে আপনি আপনার পছন্দের পর্যায়গুলি যোগ করতে পারেন। প্রকৃতপক্ষে, Gradle জীবনচক্রকে "কাস্টমাইজেশন" করার অনুমতি দেয়: আপনি নিয়মিত জীবনচক্রে যতটা চান অতিরিক্ত পর্যায় যোগ করতে পারেন।

এটা একটা গোলমেলে, প্রতিটি প্রজেক্টের জন্য প্রয়োজনীয় পর্যায়গুলির সংখ্যা এবং তাদের নাম উভয়ই নিয়ে আসতে হবে: integration-test , integration-tests , integration-testing , it (অলসদের জন্য), ইত্যাদি। বিকল্পগুলি অন্তহীন।

স্নোফ্লেক সিন্ড্রোম

ম্যাভেন প্রতিটি প্রকল্পকে নিয়মিত স্ট্যান্ডার্ড প্রকল্প হিসাবে বিবেচনা করে। এবং যদি আপনার নির্দিষ্ট প্রয়োজন থাকে, তবে এটির জন্য একটি প্লাগইন লেখা সম্ভব। একটি ম্যাভেন প্লাগইন লেখা অবশ্যই মজাদার নয়; তাই, আপনি শুধুমাত্র একটি লিখবেন যখন এটি প্রয়োজন হবে, শুধুমাত্র এই কারণে নয় যে আপনি সিদ্ধান্ত নিয়েছেন যে আইনটি আপনার ক্ষেত্রে প্রযোজ্য নয়।

গ্রেডল দাবি করে যে নমনীয়তার অভাব একটি সমস্যা; তাই, এটা ঠিক করতে চায়। আমি বিপরীতভাবে দাঁড়িয়েছি: আমার বিল্ড টুলের জন্য নমনীয়তার অভাব একটি বৈশিষ্ট্য, একটি বাগ নয়। Gradle বিল্ড হ্যাক করা সহজ করে তোলে। অতএব, যে কেউ তাদের প্রকল্পটিকে একটি বিশেষ স্নোফ্লেক মনে করে এবং কাস্টমাইজেশনের যোগ্য তারা আনন্দের সাথে তা করবে। বাস্তবতা পরীক্ষা: এটি খুব কমই হয়; যখন এটি হয়, এটি ফ্রেমওয়ার্কের জন্য, নিয়মিত প্রকল্প নয়। Gradle প্রবক্তারা বলছেন যে এটি এখনও সহজ কনফিগারেশনের অনুমতি দেওয়ার সময় মান অফার করে। বিষয়টির মূল বিষয় হল এটি একটি আদর্শ নয় যদি এটি কারও ইচ্ছায় পরিবর্তন করা যায়।

গ্রেডল হল অ্যান্ড্রয়েড প্রোজেক্টের জন্য ডি ফ্যাক্টো বিল্ড টুল। আমি যে কোম্পানির জন্য কাজ করেছি তার একটিতে, কেউ সোনার চালানোর জন্য গ্র্যাডল বিল্ডে কাস্টম গ্রোভি কোড লিখেছে এবং মেট্রিক্সগুলি অভ্যন্তরীণ সোনার উদাহরণে পাঠায়। সেই সময়ে কোন আউট-অফ-দ্য-বক্স সোনার প্লাগইন ছিল না, বা আমি অনুমান করি এটি কাটা হয়নি। এ পর্যন্ত সব ঠিকই.

যখন অন্য একটি দল কোম্পানির দ্বিতীয় অ্যান্ড্রয়েড প্রকল্প তৈরি করে, তারা প্রথম প্রকল্পের কাঠামো এবং বিল্ড ফাইলটি কপি-পেস্ট করে। এই সময়ে সোনার-নির্দিষ্ট কোড থেকে একটি অভ্যন্তরীণ গ্রেডল প্লাগইন তৈরি করা বুদ্ধিমানের কাজ হবে। কিন্তু তারা তা করেনি কারণ গ্রেডল বিল্ডটি হ্যাক করা এত সহজ করেছে। এবং আমি, গ্রেডল-বিদ্বেষী, প্লাগইন তৈরি করার জন্য এটি নিজের উপর নিয়েছিলাম। এটি একটি ভাল বিকাশকারী অভিজ্ঞতা হতে পারে, অন্তত বলতে. মানসম্পন্ন ডকুমেন্টেশনের অভাব এবং একটি টাইপ না করা ভাষা (গ্রুভি) ব্যবহার করে, আমি অবজেক্টের গঠন প্রিন্ট করার জন্য কনসোল ব্যবহার করেছি।

উপসংহার

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

আমরা, বিকাশকারী, মানুষ: আমরা ভাবতে চাই যে আমাদের প্রকল্পগুলি অন্যদের থেকে আলাদা। অধিকাংশ সময়, তারা না. কাস্টমাইজেশন আমাদের অহংকে সন্তুষ্ট করার একটি উপায় মাত্র। নমনীয় বিল্ড টুল আমাদের এই ধরনের কাস্টমাইজেশন বাস্তবায়ন করতে দেয়, তা নিশ্চিত হোক বা না হোক।

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

মূলত 6ই আগস্ট, 2023-এ A Java Geek এ প্রকাশিত