चींटी + आइवी वी.एस. मावेन: चलो एक साथ रहते हैं

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

* यह लिखा, मुझे याद है, कहीं अपाचे ने खुद कहा था कि मावेन का समय आ गया था, चींटी से दूर जाने की कोशिश करें। लेकिन उसे वह नहीं मिला, जिसकी उसे तलाश थी।

काश, हर कोई जानता है कि ज्यादातर कंपनियों / परियोजनाओं में, बिल्ड प्रबंधन जैसे एक पहलू स्वयं डेवलपर्स हैं। इसलिए, इंटरनेट पर इस विषय पर डेवलपर्स की राय हावी है। मैंने सभी प्रणालियों के उपयोग के सभी पेशेवरों और विपक्षों के विस्तृत विश्लेषण के साथ कई लेख पढ़े, और यह दुखी हो गया। इन लेखों का मुख्य लक्ष्य कोड को संकलित करना था। खैर, कभी-कभी आपको अभी भी एक आर्काइव, इंस्टॉलेशन करना पड़ता है, और इसे कहीं भी एफ़टीपी पर अपलोड करने या टॉमकैट पर तैनात करने के लिए अपलोड करना पड़ता है। सुविधाजनक निर्भरता प्रबंधन, ज़ाहिर है, एक बहुत ही सुविधाजनक विशेषता है, इसलिए इसे ध्यान में रखा जाता है। और वह सब है। और फिर एंट + आइवी मावेन के साथ तुलना करना शुरू करते हैं।
कई लोगों के लिए, यह संभवतः एक आश्चर्य के रूप में आएगा कि डीईवी और क्यूए के अलावा टीएल, पीएम, पीओ, पीएसओ, सपोर्ट, सीपीई, एल 10 एन, इंस्टॉलेशन, डिजाइनर और कई अन्य स्थान हैं जहां सामग्री आती है, जो उत्पाद वितरण का हिस्सा भी बनना चाहिए। इस खोज के आधार पर, यह स्पष्ट हो जाता है कि DEV में प्रक्रिया को छोड़ने की शक्ति नहीं है ... प्रभावी। इसलिए, बड़ी परियोजनाओं में, अलग-अलग बिल्ड फैक्ट्री टीमें हैं। लेकिन यह पूरी तरह से अलग कहानी के लिए एक विषय है।
अपने विषय पर लौटते हुए, हम इस लेख के मुख्य बिंदु पर आए। चींटी सिर्फ एक बिल्ड टूल है, मावेन पहले से ही एक प्रोजेक्ट मैनेजमेंट टूल है ।
खैर, अब, इस थीसिस से शुरू करते हुए, हम दो प्रणालियों की तुलना पूरी तरह से करेंगे।
मैंने बहुत बार लोगों को एक उदाहरण के साथ चींटी को समझाते हुए मावेन का उपयोग करने का तरीका जानने की कोशिश की। यानी दिखाएँ कि कैसे चीजें हैं जो सभी को मावेन में एंटोम करने के लिए उपयोग की जाती हैं। और वे इसे build.xml और pom.xml की तुलना करके दिखाते हैं।
लेकिन इन दोनों फाइलों की तुलना करना मौलिक रूप से गलत है।
विकी:

मावेन, अन्य अपाचे चींटी परियोजना बिल्डर के विपरीत, परियोजना के अनिवार्य निर्माण के बजाय एक घोषणापत्र प्रदान करता है।

दूसरे शब्दों में, build.xml में हम क्रमिक रूप से अन्य लक्ष्यों की घोषणा करके हमारे लक्ष्यों का वर्णन करते हैं, जो क्रमबद्ध रूप से आदेशों को निष्पादित करने के समान है। Build.xml लिखने की प्रक्रिया बिल्ड स्क्रिप्ट लिखने से ज्यादा कुछ नहीं है। हम कुछ लक्ष्यों को दूसरों में जोड़ते हैं, जो एक फ़ंक्शन कॉल का एक उदाहरण बनाता है, हालांकि स्पष्ट रूप से नहीं - लेकिन निर्भरता के पदानुक्रम के माध्यम से। हम पूरी विधानसभा प्रक्रिया को पूरी तरह से डिजाइन करेंगे।
Pom.xml में, हमारे पास वह स्वतंत्रता नहीं है। वास्तव में, मावेन पहले से ही जानता है कि यदि आपकी परियोजना के पास एक उपयुक्त संरचना है तो आपकी परियोजना के साथ क्या करना है। Pom.xml में, हम बस प्रोजेक्ट का वर्णन करते हैं - यह वह जानकारी है जो XML में क्रमबद्ध होती है। और मावेन के सफल उपयोग के लिए, यह पता चला है कि हमें इन सभी जीवन चक्रों, चरणों और अन्य चीजों को समझने की आवश्यकता है। हमें यह सीखने की आवश्यकता है कि मावेन को हमारी क्या आवश्यकता है और यह कैसे काम करता है, और pom.xml में हमारी परियोजना का वर्णन करता है। यह आमतौर पर समस्या है। आमतौर पर DEV टीमों में इस तरह के "स्वतंत्रता का प्रतिबंध" बेहद नकारात्मक माना जाता है। अपनी सुविधा को डिजाइन करने के बजाय, आपको यह पता लगाना होगा कि अन्य लोगों के कोड कैसे काम करते हैं, खुद को इन प्रतिबंधों के ढांचे में चलाएं, और इसी तरह। क्यों?
खैर, सबसे पहले, अपने आप में स्वतंत्रता का प्रतिबंध इतना बुरा नहीं है। इस विषय को विकसित करते हुए, हम असेंबलर वीएस जावा होलीवर में फिसल सकते हैं, लेकिन हम ऐसा नहीं करेंगे। हमें बस याद है कि हम कितनी बार एससीएम में .classpath और IDE फ़ाइलों को देखते हैं। यह मुश्किल है कि कभी-कभी यह समझ में नहीं आता है कि इंक्लूज़न का निर्माण कैसे होता है। xml, डिबग करना कितना मुश्किल है। यह समझना कितना कठिन है कि कौन सा मॉड्यूल पहले जा रहा है, और यह जार युद्ध में क्यों नहीं आया। और जब केवल वजन 3 जी हो जाता है, तो हम विधानसभा प्रक्रिया को अनुकूलित करने पर अपने मानव घंटे खर्च करेंगे। जब हमारे प्रबंधक किसी अन्य उत्पाद के साथ नए एकीकरण के साथ आते हैं, जब वे स्थानीयकरण या सेवा पैक के वितरण के सिद्धांतों को बदलते हैं, तो हम उन्हें समाधान डिजाइन पर भी खर्च करेंगे। सामान्य तौर पर, बहुत अधिक सिरदर्द।
अब यह देखने की कोशिश करें कि मावेन हम पर क्या थोपता है, स्वतंत्रता के प्रतिबंध के रूप में नहीं, बल्कि एक तरह के मानकीकरण के रूप में। मावेन का उपयोग करते हुए चारों ओर एक नज़र डालें, हम CI सिस्टम में, SCM में, इश्यू ट्रैकर, बैकलॉग, मेट्रिक्स और कहीं भी एकीकृत कर सकते हैं। हम एक बटन के साथ उत्पाद जारी कर सकते हैं। आखिरकार, यह सब इस मानकीकरण के लिए सटीक रूप से संभव हो गया (निश्चित रूप से, चींटी के साथ ऐसा करना संभव है, लेकिन किस कीमत पर?)। और 90% मामलों में अब विधानसभा की प्रक्रिया के अनुकूलन की प्रक्रिया एक मॉड्यूल का विभाजन कई छोटे लोगों में होता है जिन्हें समानांतर में इकट्ठा किया जा सकता है। विकास प्रक्रिया में अन्य प्रतिभागियों के साथ एकीकरण भी काफी सरल हो गया है और पारदर्शी हो गया है - प्रत्येक टीम का अपना मावेन रिपॉजिटरी (या एक सामान्य कॉर्पोरेट) हो सकता है, और हम केवल शीर्ष प्रबंधकों के निर्णय द्वारा pom.xml में कलाकृतियों के संस्करण को बदलते हैं।

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

उपयोगी लिंक:
आइवी खुद की तुलना मावेन से करता है: ant.apache.org/ivy/m2comparison.html
Codehaus से तुलना: docs.codehaus.org/display/MAVEN/Feature+Comparisons
एक और दिलचस्प बिंदु: xhab.blogspot.com/2006/09/antivy-vs-maven-my-biased-opinion.html