java - चींटी या मेवेन के बजाय ग्रैडल का उपयोग क्यों करें?




maven ant build-process gradle (9)

यह थोड़ा विवादास्पद हो सकता है, लेकिन ग्रैडल इस तथ्य को छिपा नहीं देता है कि यह पूरी तरह से प्रोग्रामिंग भाषा है।

चींटी + चींटी-contrib अनिवार्य रूप से एक ट्यूरिंग पूर्ण प्रोग्रामिंग भाषा है कि कोई भी वास्तव में प्रोग्राम करना चाहता है।

मेवेन पूरी तरह से घोषणा करने की कोशिश करने के विपरीत दृष्टिकोण लेने की कोशिश करता है और आपको तर्क की आवश्यकता होने पर प्लगइन लिखने और संकलित करने के लिए मजबूर करता है। यह एक परियोजना मॉडल भी लगाता है जो पूरी तरह से लचीला है। Gradle इन सभी उपकरणों में से सबसे अच्छा जोड़ती है:

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

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

जावा पर लक्षित एक और निर्माण उपकरण वास्तव में मुझे क्या मिलता है?

यदि आप किसी अन्य टूल पर ग्रैडल का उपयोग करते हैं, तो क्यों?


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

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


यह मेरा जवाब नहीं है, लेकिन यह निश्चित रूप से मेरे साथ गूंजता है। यह अक्टूबर 2012 से थॉटवर्क्स टेक्नोलॉजी रडार से है :

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


मैं खुद को क्रोध में Gradle का उपयोग नहीं करता (केवल एक खिलौना प्रोजेक्ट) [लेखक का मतलब है कि उन्होंने अभी तक केवल एक खिलौना परियोजना पर ग्रैडल का उपयोग किया है, न कि ग्रैडल खिलौना प्रोजेक्ट है - टिप्पणियां देखें] , लेकिन मैं कहूंगा इसका उपयोग करने पर विचार करने वाले कारणों से चींटी और मेवेन की निराशा होती है।

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

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

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

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

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


कई उद्देश्यों के लिए ग्रैडल का उपयोग किया जा सकता है - यह चींटियों की तुलना में एक बेहतर स्विस सेना चाकू है - लेकिन यह विशेष रूप से बहु-परियोजना निर्माण पर केंद्रित है।

सबसे पहले, ग्रैडल एक निर्भरता प्रोग्रामिंग टूल है जिसका अर्थ है कि यह एक प्रोग्रामिंग टूल है। ग्रैडल के साथ आप अपने सेटअप में किसी भी यादृच्छिक कार्य को निष्पादित कर सकते हैं और ग्रैडल यह सुनिश्चित करेगा कि सभी घोषित निर्भरता ठीक से और समय पर निष्पादित हों। आपका कोड किसी भी प्रकार के लेआउट (पेड़, फ्लैट, बिखरे हुए, ...) में कई निर्देशिकाओं में फैलाया जा सकता है।

ग्रैडल के दो अलग-अलग चरणों हैं: मूल्यांकन और निष्पादन। असल में, मूल्यांकन के दौरान ग्रैडल उन निर्देशिकाओं में बिल्ड स्क्रिप्ट की तलाश और मूल्यांकन करेगा, जिन्हें देखना चाहिए। निष्पादन के दौरान ग्रैडल उन कार्य निष्पादित करेगा जो मूल्यांकन कार्य के दौरान खाता कार्य अंतर-निर्भरताओं को लेते हुए लोड किए गए हैं।

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

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

मल्टी-प्रोजेक्ट में ग्रैडल दोनों अनुकूलनीय और बिल्ड की संरचना और वास्तुकला के अनुकूल हैं। आपको अपने निर्माण उपकरण में अपनी संरचना या वास्तुकला को अनुकूलित करने की आवश्यकता नहीं है जैसा कि मेवेन के साथ आवश्यक होगा।

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


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

तो यदि आप मानक जावा निर्माण करना चाहते हैं, जैसे मैवेन में, लेकिन परीक्षण कार्य को कुछ कस्टम कदम करना है जो नीचे दिखेगा।

build.gradle:

apply plugin:'java'
task test{
  doFirst{
    ant.copy(toDir:'build/test-classes'){fileset dir:'src/test/extra-resources'}
  }
  doLast{
    ...
  }
}

इसके शीर्ष पर यह ग्रोवी सिंटैक्स का उपयोग करता है जो एंटी / मेवेन के एक्सएमएल को अधिक अभिव्यक्ति शक्ति देता है।

यह चींटी का एक सुपरसेट है - आप सभी चींटियों को धीरे-धीरे नाइसर, ग्रोवी-जैसे वाक्यविन्यास, यानी के साथ उपयोग कर सकते हैं।

ant.copy(file:'a.txt', toDir:"xyz")

या

ant.with{
  delete "x.txt"
  mkdir "abc"
  copy file:"a.txt", toDir: "abc"
}

Gradle मज़ा वापस सॉफ्टवेयर / संयोजन सॉफ्टवेयर में डाल दिया। मैंने अपने पूरे करियर को सॉफ़्टवेयर बनाने के लिए चींटी का उपयोग किया और मैंने हमेशा देव काम के वास्तविक "बिल्डिट" हिस्से को एक आवश्यक बुराई माना है। कुछ महीने पहले हमारी कंपनी बाइनरी रेपो (वीसीएस में जार में उर्फ ​​जांच) का उपयोग न करने से थक गई थी और मुझे इसकी जांच करने का कार्य दिया गया था। आईवी के साथ शुरू किया गया क्योंकि इसे चींटी के शीर्ष पर बोल्ट किया जा सकता था, मेरे द्वारा निर्मित मेरे निर्मित कलाकृतियों को प्रकाशित करने में बहुत भाग्य नहीं था। मैं maven के लिए गया और एक्सएमएल के साथ दूर हैक किया, कुछ सरल सहायक libs के लिए शानदार काम किया, लेकिन मैं तैनाती के लिए तैयार अनुप्रयोगों को बंडल करने की कोशिश कर गंभीर समस्याओं में भाग गया। प्लगइन और रीडिंग फ़ोरम को थोड़ी देर तक परेशान कर दिया और विभिन्न प्लगइन्स के लिए समर्थन जार डाउनलोड करने के घावों को घायल कर दिया जो मुझे कठिन समय का उपयोग कर रहा था। आखिरकार मैं धीरे-धीरे गया (इस बिंदु पर काफी कड़वा हो रहा था, और नाराज था कि "यह मुश्किल नहीं होना चाहिए!")

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

  • जावा डेवलपर्स के लिए groovy बहुत सहज है
  • दस्तावेज भयानक करने के लिए बहुत अच्छा है
  • लचीलापन अंतहीन है

अब मैं अपने निर्माण प्रक्रिया में जोड़ने के लिए नई सुविधाओं को सोचने की कोशिश कर रहा हूं। वह कितना बीमार है?


मैं आंशिक रूप से एड स्टैब के साथ सहमत हूं। धीरे-धीरे मैवेन की तुलना में अधिक शक्तिशाली है और अधिक लचीलापन दीर्घकालिक प्रदान करता है।

मेवेन से धीरे-धीरे जाने के लिए मूल्यांकन करने के बाद, हमने धीरे-धीरे सामना करने वाले दो मुद्दों के लिए स्वर्ग में चिपकने का फैसला किया (गति मेवेन से धीमी है, प्रॉक्सी काम नहीं कर रही थी)।


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

एक अन्य संबंधित शब्द बिल्ड ऑटोमेशन है जो सॉफ़्टवेयर निर्माण और संबंधित प्रक्रियाओं के निर्माण को स्वचालित करने की प्रक्रिया है: बाइनरी कोड में कंप्यूटर स्रोत कोड संकलित करना, पैकेजिंग बाइनरी कोड और स्वचालित परीक्षण चलाना।

अन्य भाषाओं के लिए कुछ समान निर्माण प्रणाली हैं ( here पूरी सूची देखें):

  1. अपाचे चींटी और अपाचे मेवेन - जावा
  2. एसबीटी (सरल बिल्ड टूल) - स्कैला के लिए (प्ले फ्रेमवर्क आदि)
  3. आप - पायथन आधारित निर्माण उपकरण
  4. रेक (अपाचे बिल्डर) - रूबी
  5. Leiningen लिए Leiningen




java maven ant build-process gradle