क्या ग्रैडल वास्तव में मावेन से बेहतर है? - मेरा अंतिम फैसला

मैं तकनीकी सामग्री ट्वीट करता हूं जिसे मैं दिलचस्प मानता हूं, लेकिन मजेदार ट्वीट ही सबसे अधिक जुड़ाव रखते हैं। मैंने मार्च में जावालैंड सम्मेलन में भाग लिया, ग्रैडल बूथ पर मेरी नजर पड़ी और मुझे यह रत्न मिला:

बेशक, किसी बिंदु पर, एक फैनबॉय ने धागे को हाईजैक कर लिया और ग्रैडल की तथाकथित श्रेष्ठता का दावा किया। इस पोस्ट में, मैं अपने रुख पर कुछ प्रकाश डालना चाहता हूं, ताकि मैं एक ही "तर्क" को बार-बार खारिज करने के बजाय लोगों को इस ओर निर्देशित कर सकूं।

इसे प्रबंधित करने के लिए, मुझे समय पर वापस जाना होगा। सॉफ्टवेयर विकास एक तेजी से बदलता क्षेत्र है, और हमारी अधिकांश समझ व्यक्तिगत अनुभव पर आधारित है। तो यहाँ मेरा है.

मेरा पहला निर्माण उपकरण: चींटी

मैंने 2002 में जावा में विकास करना शुरू किया था। उस समय, कोई निर्माण उपकरण नहीं थे: हमने आईडीई के माध्यम से संकलन और निर्माण किया। रिकॉर्ड के लिए, मैंने सबसे पहले जावा के लिए विज़ुअल एज का उपयोग किया; फिर, मैं बोरलैंड जेबिल्डर में चला गया।

आईडीई के साथ निर्माण में एक बड़ी समस्या है: प्रत्येक डेवलपर के पास समर्पित सेटिंग्स होती हैं, इसलिए आर्टिफैक्ट पीढ़ी डेवलपर-मशीन संयोजन पर निर्भर करती है।

गैर-दोहराए जाने योग्य बिल्ड एक सदियों पुरानी समस्या है। दोहराने योग्य बिल्ड के साथ मेरा पहला अनुभव अपाचे चींटी है:

अपाचे एंट एक जावा लाइब्रेरी और कमांड-लाइन टूल है जिसका मिशन बिल्ड फ़ाइलों में वर्णित प्रक्रियाओं को लक्ष्य और विस्तार बिंदुओं के रूप में एक दूसरे पर निर्भर करना है। चींटी का मुख्य ज्ञात उपयोग जावा अनुप्रयोगों का निर्माण है। चींटी जावा अनुप्रयोगों को संकलित करने, इकट्ठा करने, परीक्षण करने और चलाने की अनुमति देने वाले कई अंतर्निहित कार्यों की आपूर्ति करती है। चींटी का उपयोग गैर जावा एप्लिकेशन, उदाहरण के लिए C या C++ एप्लिकेशन बनाने के लिए भी प्रभावी ढंग से किया जा सकता है। आम तौर पर, चींटी का उपयोग किसी भी प्रकार की प्रक्रिया को संचालित करने के लिए किया जा सकता है जिसे लक्ष्य और कार्यों के संदर्भ में वर्णित किया जा सकता है।

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

चींटी तीन मुख्य अमूर्तताओं पर आधारित है:

• एक कार्य कार्य की एक परमाणु इकाई है, उदाहरण के लिए , जावा फ़ाइलों को संकलित करने के लिए javac , वेब संग्रह को इकट्ठा करने के लिए war , आदि। चींटी बहुत सारे कार्य आउट-ऑफ़-द-बॉक्स प्रदान करती है लेकिन कस्टम जोड़ने की अनुमति देती है।
• लक्ष्य कार्यों की एक सूची है.
• आप कार्यों के बीच निर्भरता को परिभाषित कर सकते हैं, जैसे संकलन के आधार पर पैकेज । इस संबंध में, आप चींटी को वर्कफ़्लो निष्पादन इंजन के रूप में देख सकते हैं।

मैं जल्द ही चींटी में "धाराप्रवाह" हो गया। एक सलाहकार के रूप में, मैं एक कंपनी से दूसरी कंपनी, एक प्रोजेक्ट से दूसरे प्रोजेक्ट पर जाता रहा। प्रारंभ में, मैंने ज्यादातर चींटी की स्थापना की, लेकिन समय बीतने के साथ चींटी अधिक व्यापक हो गई, और मुझे मौजूदा चींटी सेटअप का सामना करना पड़ा। मैं अपनी परियोजनाओं में सुसंगत था, लेकिन अन्य परियोजनाएं एक-दूसरे से बहुत अलग थीं।

हर बार, किसी नए प्रोजेक्ट पर पहुंचते समय, आपको कस्टम बिल्ड को समझने के लिए एंट सेटअप को ध्यान से पढ़ना होगा। इसके अलावा, प्रत्येक परियोजना की संरचना अलग थी। कुछ लोग अपने स्रोत src में रखते हैं, कुछ sources में रखते हैं, कुछ नेस्टेड संरचना में रखते हैं, आदि।

मुझे एक बार एक सामान्य बिल्ड फ़ाइल याद है जिसने किसी संगठन की संपूर्ण परियोजना आवश्यकताओं को समायोजित करने का प्रयास किया था। इसने XML की 2,000 से अधिक लाइनों में 80 से अधिक लक्ष्यों को परिभाषित किया। मुझे यह समझने में बहुत कम समय लगा कि मदद से इसका उपयोग कैसे किया जाए और परियोजनाओं को तोड़े बिना इसमें सुधार करने में सक्षम होने के लिए और भी अधिक समय लगा।

मेरा दूसरा निर्माण उपकरण: मावेन

उपरोक्त परियोजना ने मुझे बहुत सोचने पर मजबूर कर दिया। मैं स्थिति में सुधार करना चाहता था क्योंकि रखरखाव करने वालों ने पहले ही चींटी की सीमाएँ बढ़ा दी थीं। उस समय, मैं अपने दोस्त फ्रेडी मैलेट (सोनार प्रसिद्धि) के साथ काम कर रहा था। हमने बात की और उसने मुझे मावेन की ओर इशारा किया। मैंने एक बार मावेन के साथ एक प्रोजेक्ट बनाया था लेकिन कोई अन्य पूर्व अनुभव नहीं था। मैंने घंटों तक दस्तावेज़ीकरण का अध्ययन किया, और परीक्षण-और-त्रुटि प्रयासों के माध्यम से, फ़्रेडी के संरक्षण में, पूरी चींटी बिल्ड फ़ाइल को एक साधारण पैरेंट पीओएम में स्थानांतरित कर दिया।

चींटी में, आपको प्रत्येक प्रोजेक्ट में सब कुछ परिभाषित करने की आवश्यकता होगी। उदाहरण के लिए, चींटी को संकलन के लिए जावा फ़ाइलों के स्थान को कॉन्फ़िगर करने की आवश्यकता होती है; मेवेन मानता है कि वे src/main/java के अंतर्गत हैं, हालांकि इसे ओवरराइड करना संभव है। मेवेन ने कॉन्फ़िगरेशन दृष्टिकोण पर कन्वेंशन के साथ जावा बिल्ड फ़ील्ड में क्रांति ला दी। आजकल, बहुत सारे सॉफ़्टवेयर डिफ़ॉल्ट रूप से समझदार कॉन्फ़िगरेशन प्रदान करते हैं।

उन डेवलपर्स के लिए जो एक प्रोजेक्ट से दूसरे प्रोजेक्ट पर जाते हैं, जैसा कि मैंने किया, इसका मतलब है कि किसी नए प्रोजेक्ट में शामिल होने पर संज्ञानात्मक भार बहुत कम होता है। मुझे उम्मीद है कि जावा स्रोत src/main/java के अंतर्गत स्थित होंगे। मावेन सम्मेलन परियोजना की संरचना से परे भी जारी हैं। वे परियोजना के जीवनचक्र को भी परिभाषित करते हैं, संकलन से लेकर दूरस्थ रजिस्ट्री में कलाकृतियों को अपलोड करने तक, यूनिट और एकीकरण परीक्षण के माध्यम से।

अंत में, जूनियर डेवलपर्स इससे बेखबर रहते हैं, लेकिन मेवेन ने निर्भरता प्रबंधन शब्द को परिभाषित किया। इसने आर्टिफैक्ट रजिस्ट्रियों का विचार पेश किया, जहां से कोई अपरिवर्तनीय निर्भरता डाउनलोड कर सकता है और आर्टिफैक्ट को पुश कर सकता है। उस समय से पहले, प्रत्येक परियोजना को निर्भरता को अपने समर्पित भंडार में संग्रहीत करना पड़ता था।

रिकॉर्ड के लिए, उपर्युक्त परियोजना पर कुछ संग्रहीत निर्भरताएँ थीं। जब मैं एंट से मावेन में स्थानांतरित हुआ, तो मुझे सटीक निर्भरता संस्करण ढूंढना पड़ा। अधिकांश के लिए, यह सीधा था, जैसा कि फ़ाइल नाम या JAR के मेनिफेस्ट में था। हालाँकि, एक को अतिरिक्त कक्षाओं के साथ अद्यतन किया गया था।

अपरिवर्तनीयता के लिए बहुत कुछ।

बाद के सभी निर्माण उपकरणों पर मावेन का गहरा प्रभाव था: उन्होंने खुद को मावेन के संदर्भ में परिभाषित किया।

मेरा कोई निर्माण उपकरण नहीं: ग्रैडल

ग्रैडल का प्राथमिक दावा मावेन की कमियों को ठीक करना था, या कम से कम इसे ऐसा माना जाता था। जबकि मावेन को फटकार से छूट नहीं मिली है, ग्रैडल ने माना कि सबसे महत्वपूर्ण मुद्दा लचीलेपन की कमी थी। यह एक आश्चर्यजनक धारणा है क्योंकि मावेन ने ठीक इसी तरह चींटी की तुलना में सुधार किया है। मावेन परियोजनाओं में समान संरचनाएं होती हैं और समान जीवनचक्र का उपयोग होता है: प्रभाव में कम से कम आश्चर्य का सिद्धांत । इसके विपरीत, ग्रैडल जीवनचक्र सहित लगभग हर निर्माण पहलू को अनुकूलित करने की अनुमति देता है।

लचीलेपन के तर्क का सामना करने से पहले, मैं दो महान मूल ग्रैडल विशेषताओं को स्वीकार करता हूं जिन्हें मावेन ने बाद में लागू किया: ग्रैडल डेमॉन और ग्रैडल रैपर।

मेवेन और ग्रैडल दोनों जावा एप्लिकेशन हैं जो जेवीएम पर चलते हैं। JVM प्रारंभ करना समय और संसाधनों की दृष्टि से महंगा है। लाभ यह है कि लंबे समय तक चलने वाला JVM समय के साथ JIT-ed कोड को अनुकूलित करेगा। यदि आप जेवीएम स्टार्टअप समय को ध्यान में रखते हैं, तो अल्पकालिक कार्यों के लिए लाभ शून्य और हानिकारक भी है। ग्रैडल ग्रैडल डेमॉन के साथ आया। जब आप ग्रैडल चलाते हैं, तो यह एक चालू डेमॉन की तलाश करेगा। यदि नहीं, तो यह एक नई शुरुआत करेगा. कमांड-लाइन ऐप सब कुछ डेमॉन को सौंप देगा। जैसा कि इसके नाम से पता चलता है, कमांड लाइन समाप्त होने पर डेमॉन रुकता नहीं है। डेमॉन जेवीएम के लाभों का लाभ उठाता है।

संभावना यह है कि आपका एप्लिकेशन आपके वर्तमान बिल्ड टूल से अधिक समय तक चलेगा। क्या होता है जब आपको अब से पांच साल बाद किसी बग को ठीक करने की आवश्यकता होती है, और आपको पता चलता है कि प्रोजेक्ट का निर्माण उपकरण ऑनलाइन उपलब्ध नहीं है? ग्रैडल के रैपर के पीछे का विचार प्रोजेक्ट के साथ सटीक ग्रैडल संस्करण और इंटरनेट पर पूर्ण संस्करण डाउनलोड करने के लिए पर्याप्त कोड रखना है। दुष्प्रभाव के रूप में, डेवलपर्स को ग्रैडल को स्थानीय रूप से स्थापित करने की आवश्यकता नहीं है; किसी भी विसंगति से बचते हुए सभी एक ही संस्करण का उपयोग करते हैं।

ग्रैडल के लचीलेपन को ख़त्म करना

ग्रैडल उपरोक्त दो बेहतरीन विशेषताएं लेकर आया, जिन्हें मावेन ने एकीकृत किया, जिससे यह साबित हुआ कि प्रतिस्पर्धा अच्छी है। इसके बावजूद, मुझे अभी भी ग्रैडल का कोई लाभ नहीं मिला।

मैं भावनात्मक पक्ष को दूर करने की कोशिश करूंगा। अपनी शुरुआत में, ग्रैडल मार्केटिंग ने हर संभव अवसर पर मावेन को नीचा दिखाने की कोशिश की, पागल तुलना चार्ट प्रकाशित किए, और आम तौर पर अपने संचार में बहुत आक्रामक था। मान लीजिए कि यह चरण बाजार में अपनी जगह तलाशने की कोशिश कर रही एक युवा कंपनी के लिए स्वीकार्य समय से कहीं अधिक समय तक चला। आप कह सकते हैं कि ग्रैडल अपने दृष्टिकोण में बहुत ओडिपियन था: अपने मावेन "पिता" को मारने की कोशिश कर रहा था। अंततः, इतने वर्षों के बाद, ऐसा लगता है कि वह समझदार हो गया है और अब "मावेन से प्यार करता है।"

याद रखें कि मावेन के कार्यभार संभालने से पहले, प्रत्येक चींटी परियोजना तदर्थ थी। मावेन ने उसे ख़त्म कर दिया। इसने वर्ल्ड वाइल्ड वेस्ट में कस्टम परियोजनाओं के लिए कानून लाया। आप कानून से असहमत हो सकते हैं, लेकिन फिर भी यह कानून है और हर किसी को इसके साथ खड़ा होना होगा। मावेन मानक इतने मजबूत हैं कि भले ही कुछ मापदंडों, जैसे स्रोत स्थान, को ओवरराइड करना संभव है, कोई भी कभी भी ऐसा नहीं करता है।

मुझे ग्रैडल के लचीलेपन के दो लक्षण अनुभव हुए। मुझे संदेह है कि कहीं अधिक मौजूद है।

कस्टम जीवनचक्र चरण

मावेन चार चरणों में एकीकरण परीक्षण का प्रबंधन करता है, क्रम में चलाएं:

1. pre-integration-test : परीक्षण के लिए आवश्यक कोई भी चीज़ सेट करें
2. integration-test : परीक्षण निष्पादित करें
3. post-integration-test : संसाधनों को साफ़ करें, यदि कोई हो
4. verify : परीक्षण के परिणामों के आधार पर कार्य करें

मैंने कभी भी पूर्व और बाद के चरणों का उपयोग नहीं किया, क्योंकि प्रत्येक परीक्षण में एक समर्पित सेटअप और टियरडाउन तर्क था।

दूसरी ओर, ग्रैडल को एकीकरण परीक्षणों के बारे में कोई जानकारी नहीं है । फिर भी, ग्रैडल के प्रशंसक ख़ुशी से समझाएँगे कि आप अपने इच्छित चरण जोड़ सकते हैं। दरअसल, ग्रैडल जीवनचक्र को "अनुकूलन" की अनुमति देता है: आप नियमित जीवनचक्र में जितने चाहें उतने अतिरिक्त चरण जोड़ सकते हैं।

यह एक गड़बड़ है, क्योंकि प्रत्येक परियोजना को आवश्यक चरणों की संख्या और उनके नाम दोनों के साथ आने की आवश्यकता होगी: integration-test , integration-tests , integration-testing , it (आलसी के लिए), आदि। विकल्प अनंत हैं।

स्नोफ्लेक सिंड्रोम

मावेन प्रत्येक परियोजना को एक नियमित मानक परियोजना के रूप में मानता है। और यदि आपकी विशिष्ट आवश्यकताएं हैं, तो उसके लिए एक प्लगइन लिखना संभव है। मावेन प्लगइन लिखना निश्चित रूप से मजेदार नहीं है; इसलिए, आप केवल तभी लिखते हैं जब यह आवश्यक हो, सिर्फ इसलिए नहीं कि आपने निर्णय लिया है कि कानून आप पर लागू नहीं होता है।

ग्रैडल का दावा है कि लचीलेपन की कमी एक मुद्दा है; इसलिए, वह इसे ठीक करना चाहता है। मैं इसके विपरीत खड़ा हूं: मेरे बिल्ड टूल के लिए लचीलेपन की कमी एक विशेषता है, बग नहीं। ग्रैडल बिल्ड को हैक करना आसान बनाता है। इसलिए, जो कोई भी सोचता है कि उनका प्रोजेक्ट एक विशेष स्नोफ्लेक है और अनुकूलन के योग्य है, वह ख़ुशी से ऐसा करेगा। वास्तविकता की जाँच: ऐसा कम ही होता है; जब यह होता है, तो यह फ्रेमवर्क के लिए होता है, नियमित परियोजनाओं के लिए नहीं। ग्रैडल समर्थकों का कहना है कि यह आसान कॉन्फ़िगरेशन की अनुमति देते हुए अभी भी मानक प्रदान करता है। मामले का सार यह है कि यह कोई मानक नहीं है कि इसे किसी की मर्जी से बदला जा सके।

ग्रैडल एंड्रॉइड प्रोजेक्ट्स के लिए वास्तविक निर्माण उपकरण है। जिन कंपनियों के लिए मैंने काम किया उनमें से एक में, किसी ने सोनार को चलाने और आंतरिक सोनार इंस्टेंस पर मेट्रिक्स भेजने के लिए ग्रैडल बिल्ड में कस्टम ग्रूवी कोड लिखा था। उस समय कोई आउट-ऑफ़-द-बॉक्स सोनार प्लगइन नहीं था, या मुझे लगता है कि उसने इसमें कटौती नहीं की थी। अब तक तो सब ठीक है।

जब दूसरी टीम ने कंपनी का दूसरा एंड्रॉइड प्रोजेक्ट बनाया, तो उन्होंने पहले प्रोजेक्ट की संरचना और बिल्ड फ़ाइल को कॉपी-पेस्ट किया। इस समय बुद्धिमानी वाली बात यह होगी कि सोनार-विशिष्ट कोड से एक आंतरिक ग्रैडल प्लगइन बनाया जाए। लेकिन उन्होंने ऐसा नहीं किया क्योंकि ग्रैडल ने बिल्ड को हैक करना इतना आसान बना दिया था। और मैं, ग्रैडल-नफरत करने वाले, ने प्लगइन बनाने का जिम्मा अपने ऊपर ले लिया। कम से कम इतना तो कहा ही जा सकता है कि यह एक बेहतर डेवलपर अनुभव हो सकता था। गुणवत्ता दस्तावेज़ीकरण की कमी और एक अलिखित भाषा (ग्रूवी) का उपयोग करते हुए, मैंने प्रगति के लिए ऑब्जेक्ट की संरचना को प्रिंट करने के लिए कंसोल का उपयोग किया।

निष्कर्ष

प्रतिस्पर्धा अच्छी है, और ग्रैडल नए विचार लाए हैं जिन्हें मावेन ने रैपर और डेमॉन में एकीकृत किया है। हालाँकि, ग्रैडल इस आधार पर बनाया गया है कि लचीलापन अच्छा है, जबकि मेरे अनुभव ने मुझे इसके विपरीत दिखाया है। चींटी बहुत लचीली थी, और एक प्रोजेक्ट से दूसरे प्रोजेक्ट तक जाने का संज्ञानात्मक भार बहुत अधिक था।

हम, डेवलपर, इंसान हैं: हम यह सोचना पसंद करते हैं कि हमारी परियोजनाएं दूसरों से अलग हैं। अधिकांश समय, वे नहीं होते हैं। अनुकूलन केवल हमारे अहंकार को संतुष्ट करने का एक तरीका है। लचीले निर्माण उपकरण हमें ऐसे अनुकूलन को लागू करने की अनुमति देते हैं, चाहे इसकी आवश्यकता हो या नहीं।

अप्रासंगिक अनुकूलन कोई लाभ नहीं लाते हैं और इन्हें विकसित करना आसान है लेकिन बनाए रखना महंगा है। यदि सॉफ़्टवेयर परिसंपत्तियों का प्रबंधन करना मेरी ज़िम्मेदारियों का हिस्सा है, तो मैं हमेशा अपने निर्माण उपकरण के लिए लचीलेपन के स्थान पर स्थिरता को चुनूँगा।

मूल रूप से 6 अगस्त, 2023 को ए जावा गीक में प्रकाशित