चींटी और मेवेन के बीच मतभेद

Question

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

Answer 1

मेवेन में आमतौर पर प्रयुक्त ओपन सोर्स प्रोजेक्ट्स का एक बड़ा भंडार भी होता है। निर्माण के दौरान मेवेन आपके लिए इन निर्भरताओं को डाउनलोड कर सकता है (साथ ही आपकी निर्भरता निर्भरता :)) एक परियोजना को थोड़ा अधिक प्रबंधनीय बनाने के इस हिस्से को बनाने के लिए।

Answer 2

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

Answer 3

Maven or Ant? इस के लिए एक बहुत ही समान प्रश्न है, जो आपको उत्तर देने में मदद कर सकता है आपके सवाल।

What is Maven? आधिकारिक साइट पर।

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

Answer 4

चींटी मुख्य रूप से एक निर्माण उपकरण है।

मेवेन एक परियोजना और निर्भरता प्रबंधन उपकरण है (जो निश्चित रूप से आपकी परियोजना भी बनाता है)।

चींटी + Ivy यदि आप मेवेन से बचना चाहते हैं तो एक बहुत अच्छा संयोजन है।

Answer 5

बस कुछ और मतभेद सूची:

• चींटी औपचारिक सम्मेलनों जरूरत नहीं है। आपको चींटी को बिल्कुल कहां कहना है कि स्रोत कहां ढूंढना है, आउटपुट कहां रखना है, आदि
• चींटी प्रक्रियात्मक है। आपको चींटी को बिल्कुल बताना होगा कि क्या करना है; इसे संकलित करने के लिए कहें, कॉपी करें, फिर संपीड़ित करें, आदि
• चींटी में जीवन चक्र नहीं है।
• मेवेन सम्मेलनों का उपयोग करता है। यह जानता है कि जब तक आप इन सम्मेलनों का पालन करते हैं, तब तक आपका स्रोत कोड स्वचालित रूप से कहां है। आपको मेवेन को यह कहने की ज़रूरत नहीं है कि यह कहां है।
• मेवेन घोषणात्मक है; आपको बस एक pom.xml फ़ाइल बनाना है और अपना स्रोत डिफ़ॉल्ट निर्देशिका में रखना है। मेवेन बाकी का ख्याल रखेगा।
• मेवेन का जीवन चक्र है। आप बस एमवीएन इंस्टॉल करें और अनुक्रम चरणों की एक श्रृंखला को निष्पादित किया जाता है।
• मेवेन में सामान्य परियोजना कार्यों के बारे में जानकारी है। परीक्षण चलाने के लिए, एमवीएन परीक्षण को सरल निष्पादित करें, जब तक कि फ़ाइलें डिफ़ॉल्ट स्थान पर हों। चींटी में, आपको सबसे पहले JUnit JAR फ़ाइल करना होगा, फिर एक क्लासपाथ बनाएं जिसमें जुनीट जार शामिल है, फिर एंटी को बताएं जहां इसे टेस्ट सोर्स कोड की तलाश करनी चाहिए, एक ऐसा लक्ष्य लिखें जो परीक्षण स्रोत को संकलित करता है और अंततः यूनिट परीक्षण निष्पादित करता है जुनीट के साथ

अद्यतन:

यह Maven: The Definitive Guide से आया है। क्षमा करें, मैं इसे पूरी तरह से उद्धृत करना भूल गया।

Answer 6

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

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

तुम भी Maven के भीतर से चींटी आदेशों को चलाने के लिए एक प्लगइन है कि वहाँ ध्यान में रखना चाहिए:

http://maven.apache.org/plugins/maven-ant-plugin/

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

https://wicket.apache.org/start/quickstart.html

Answer 7

Maven: The Definitive Guide में, मैं परिचय अनुभाग शीर्षक "The Differences Between Ant and Maven" है में Maven और चींटी के बीच मतभेदों के बारे में लिखा था। यहां एक उत्तर दिया गया है जो कुछ अतिरिक्त नोट्स के साथ उस परिचय में जानकारी का संयोजन है।

एक साधारण तुलना

मैं केवल विचार है कि, सबसे बुनियादी स्तर पर, Maven निर्मित सम्मेलनों है वर्णन करने के लिए आप इस दिखा रहा हूँ। आप देख सकते हैं आप कैसे चींटी बताने के लिए वास्तव में क्या करना है

<project name="my-project" default="dist" basedir="."> 
    <description> 
     simple example build file 
    </description> 
    <!-- set global properties for this build --> 
    <property name="src" location="src/main/java"/> 
    <property name="build" location="target/classes"/> 
    <property name="dist" location="target"/> 

    <target name="init"> 
     <!-- Create the time stamp --> 
     <tstamp/> 
     <!-- Create the build directory structure used by compile --> 
     <mkdir dir="${build}"/> 
    </target> 

    <target name="compile" depends="init" 
     description="compile the source " > 
     <!-- Compile the java code from ${src} into ${build} --> 
     <javac srcdir="${src}" destdir="${build}"/> 
    </target> 

    <target name="dist" depends="compile" 
     description="generate the distribution" > 
     <!-- Create the distribution directory --> 
     <mkdir dir="${dist}/lib"/> 

     <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file 
--> 
     <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/> 
    </target> 

    <target name="clean" 
     description="clean up" > 
    <!-- Delete the ${build} and ${dist} directory trees --> 
    <delete dir="${build}"/> 
    <delete dir="${dist}"/> 
    </target> 
</project> 

इस सरल चींटी उदाहरण में: यहाँ एक सरल चींटी निर्माण फ़ाइल है। एक संकलित लक्ष्य है जिसमें javac कार्य शामिल है जो स्रोत/मुख्य/जावा निर्देशिका में स्रोत/लक्ष्य निर्देशिका में स्रोत को संकलित करता है। आपको चींटी को बिल्कुल कहना होगा कि आपका स्रोत कहां है, जहां आप परिणामी बाइटकोड को संग्रहीत करना चाहते हैं, और इसे सभी को JAR फ़ाइल में कैसे पैकेज करना है। हालांकि कुछ हालिया घटनाएं हैं जो चींटी को कम प्रक्रियात्मक बनाने में मदद करती हैं, एंटी के साथ डेवलपर का अनुभव एक्सएमएल में लिखित प्रक्रियात्मक भाषा को कोड करने में है।

मैवेन उदाहरण के साथ पिछले चींटी उदाहरण की तुलना करें। मेवेन में, कुछ जावा स्रोत से एक जेएआर फ़ाइल बनाने के लिए, आपको बस एक साधारण pom.xml बनाना है, अपना स्रोत कोड $ {basedir}/src/main/java में रखें और फिर कमांड लाइन से mvn इंस्टॉल करें । उदाहरण Maven pom.xml जो एक ही परिणाम प्राप्त करता है।

<project> 
    <modelVersion>4.0.0</modelVersion> 
    <groupId>org.sonatype.mavenbook</groupId> 
    <artifactId>my-project</artifactId> 
    <version>1.0</version> 
</project> 

यह सब आपको अपने pom.xml में चाहिए। कमांड लाइन से चल रहा एमवीएन इंस्टॉलेशन संसाधनों को संसाधित करेगा, स्रोत संकलित करेगा, इकाई परीक्षण निष्पादित करेगा, एक जेएआर बनाएगा, और अन्य परियोजनाओं में पुन: उपयोग के लिए स्थानीय भंडार में जेएआर स्थापित करेगा। संशोधन के बिना, आप एमवीएन साइट चला सकते हैं और फिर लक्ष्य/साइट में index.html फ़ाइल ढूंढ सकते हैं जिसमें JavaDoc के लिंक और आपके स्रोत कोड के बारे में कुछ रिपोर्ट शामिल हैं।

मान्य है, यह सबसे आसान संभव उदाहरण प्रोजेक्ट है। एक परियोजना जिसमें केवल स्रोत कोड होता है और जो एक जेएआर उत्पन्न करता है। एक परियोजना जो मेवेन सम्मेलनों का पालन करती है और किसी भी निर्भरता या अनुकूलन की आवश्यकता नहीं होती है। अगर हम व्यवहार को अनुकूलित करना शुरू करना चाहते हैं, तो हमारा pom.xml आकार में बढ़ने जा रहा है, और सबसे बड़ी परियोजनाओं में आप बहुत ही जटिल मेवेन पीओएम के संग्रह देख सकते हैं जिसमें प्लगइन अनुकूलन और निर्भरता घोषणाओं का एक बड़ा सौदा शामिल है। लेकिन, यहां तक ​​कि जब आपकी प्रोजेक्ट की पीओएम फाइलें अधिक महत्वपूर्ण हो जाती हैं, तब भी वे चींटी का उपयोग करके समान आकार की परियोजना के निर्माण फ़ाइल से पूरी तरह से अलग तरह की जानकारी रखते हैं। मेवेन पीओएम में घोषणाएं हैं: "यह एक जार परियोजना है", और "स्रोत कोड src/main/java में है"। चींटी बिल्ड फाइलों में स्पष्ट निर्देश होते हैं: "यह प्रोजेक्ट है", "स्रोत src/main/java" है, "इस निर्देशिका के विरुद्ध javac चलाएं", "परिणाम target/classses में रखें", "एक जेएआर बनाएं ...." आदि। जहां एंट को प्रक्रिया के बारे में स्पष्ट होना था, वहां मेवेन में कुछ "अंतर्निहित" था जो सिर्फ यह जानता था कि स्रोत कोड कहां था और इसे कैसे संसाधित किया जाना चाहिए।

उच्च स्तर तुलना

इस उदाहरण में चींटी और Maven के बीच मतभेद? चींटी ...

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

कहाँ Maven ...

• सम्मेलनों है, यह पहले से ही पता था कि जहां अपने स्रोत कोड है क्योंकि आप का पालन किया था। यह लक्ष्य/कक्षाओं में बाइटकोड डालता है, और इसने लक्ष्य में एक जेएआर फ़ाइल बनाई।
• घोषणात्मक है। आपको बस इतना करना था कि pom.xml फ़ाइल बनाएं और अपना स्रोत डिफ़ॉल्ट निर्देशिका में रखें। मेवेन ने बाकी का ख्याल रखा।
• में एक जीवन चक्र है, जिसे आपने mvn install निष्पादित करते समय बुलाया था। इस आदेश ने मैवेन को जीवन चक्र तक पहुंचने तक अनुक्रम चरणों की एक श्रृंखला निष्पादित करने के लिए कहा। जीवन चक्र के माध्यम से इस यात्रा के दुष्प्रभाव के रूप में, मेवेन ने कई डिफ़ॉल्ट प्लगइन लक्ष्यों को निष्पादित किया, जो संकलन और जेएआर बनाने जैसी चीजें करते थे।

आइवी के बारे में क्या?

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

बनाम चींटी

1. Maven से ज्यादा महत्वपूर्ण है कि आप सॉफ्टवेयर कलाकृतियों का ट्रैक रखने के लिए एक भंडार प्रबंधक का उपयोग है। मैं downloading Nexus का सुझाव दूंगा। आप प्रॉक्सी रिमोट रिपॉजिटरीज़ के लिए नेक्सस का उपयोग कर सकते हैं और अपनी टीम के लिए आंतरिक कलाकृतियों को तैनात करने के लिए एक जगह प्रदान कर सकते हैं।
2. आपके पास सॉफ्टवेयर घटकों का उचित मॉड्यूलरेशन है। एक बड़ा मोनोलिथिक घटक समय के साथ शायद ही कभी स्केल करता है। जैसे ही आपकी परियोजना विकसित होती है, आप मॉड्यूल और उप-मॉड्यूल की अवधारणा लेना चाहेंगे। मेवेन खुद को इस दृष्टिकोण पर बहुत अच्छी तरह से उधार देता है।
3. आप अपने निर्माण के लिए कुछ सम्मेलनों को अपनाते हैं। यहां तक ​​कि यदि आप चींटी का उपयोग करते हैं, तो आपको किसी अन्य प्रकार के सम्मेलन को अपनाने का प्रयास करना चाहिए जो अन्य परियोजनाओं के अनुरूप है। जब कोई प्रोजेक्ट मेवेन का उपयोग करता है, तो इसका मतलब है कि मेवेन से परिचित कोई भी व्यक्ति निर्माण को उठा सकता है और कॉन्फ़िगरेशन के साथ परेशान किए बिना इसके साथ चलना शुरू कर सकता है ताकि यह समझ सके कि संकलन को कैसे प्राप्त किया जाए।

Answer 8

मैं एक व्यक्ति है कि कभी नहीं चींटी देखा ले सकते हैं - अपने build.xml रों यथोचित अच्छी तरह से लिखा जाता है - और वे समझ सकते हैं कि क्या हो रहा है। मैं वही व्यक्ति ले सकता हूं और उन्हें एक मेवेन पोम दिखा सकता हूं और उन्हें कोई जानकारी नहीं होगी कि क्या हो रहा है।

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

जब तक आपके पास एक साधारण परियोजना नहीं है, तब तक मेवेन सम्मेलनों को सीखना और काम करने के बारे में मेवेन तरीका काफी काम है।

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

बिल्ड सिस्टम के सबसे महत्वपूर्ण पहलू निर्भरता प्रबंधन और निर्माण नुस्खा को व्यक्त करने में लचीलापन हैं। अच्छी तरह से किया जाने पर यह कुछ हद तक सहज होना चाहिए।

Answer 9

Maven, एक फ्रेमवर्क है चींटी, एक उपकरण बॉक्स

Maven पहले से बने सड़क कार है जबकि चींटी कार भागों का एक सेट है। चींटी के साथ आपको अपनी कार बनाना है, लेकिन कम से कम अगर आपको ऑफ-रोड ड्राइविंग करने की ज़रूरत है तो आप सही प्रकार की कार बना सकते हैं।

इसे एक और तरीका रखने के लिए, मैवेन एक ढांचा है जबकि चींटी एक टूलबॉक्स है। यदि आप ढांचे की सीमाओं के भीतर काम करने में संतुष्ट हैं तो मैवेन ठीक काम करेगा। मेरे लिए समस्या यह थी कि मैं ढांचे की सीमाओं में कूद रहा था और यह मुझे बाहर जाने नहीं देगा।

एक्सएमएल शब्दाडंबर

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

पहले, Maven फ़ाइल:

<project 
    xmlns="http://maven.apache.org/POM/4.0.0" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-4_0_0.xsd"> 

    <parent> 
     <groupId>com.mycompany</groupId> 
     <artifactId>app-parent</artifactId> 
     <version>1.0</version> 
    </parent> 

    <modelVersion>4.0.0</modelVersion> 
    <artifactId>persist</artifactId> 
    <name>Persistence Layer</name> 

    <dependencies> 

     <dependency> 
      <groupId>com.mycompany</groupId> 
      <artifactId>common</artifactId> 
      <scope>compile</scope> 
      <version>${project.version}</version> 
     </dependency> 

     <dependency> 
      <groupId>com.mycompany</groupId> 
      <artifactId>domain</artifactId> 
      <scope>provided</scope> 
      <version>${project.version}</version> 
     </dependency> 

     <dependency> 
      <groupId>org.hibernate</groupId> 
      <artifactId>hibernate</artifactId> 
      <version>${hibernate.version}</version> 
      <scope>provided</scope> 
     </dependency> 

     <dependency> 
      <groupId>commons-lang</groupId> 
      <artifactId>commons-lang</artifactId> 
      <version>${commons-lang.version}</version> 
      <scope>provided</scope> 
     </dependency> 

     <dependency> 
      <groupId>org.springframework</groupId> 
      <artifactId>spring</artifactId> 
      <version>${spring.version}</version> 
      <scope>provided</scope> 
     </dependency> 

     <dependency> 
      <groupId>org.dbunit</groupId> 
      <artifactId>dbunit</artifactId> 
      <version>2.2.3</version> 
      <scope>test</scope> 
     </dependency> 

     <dependency> 
      <groupId>org.testng</groupId> 
      <artifactId>testng</artifactId> 
      <version>${testng.version}</version> 
      <scope>test</scope> 
      <classifier>jdk15</classifier> 
     </dependency> 

     <dependency> 
      <groupId>commons-dbcp</groupId> 
      <artifactId>commons-dbcp</artifactId> 
      <version>${commons-dbcp.version}</version> 
      <scope>test</scope> 
     </dependency> 

     <dependency> 
      <groupId>com.oracle</groupId> 
      <artifactId>ojdbc</artifactId> 
      <version>${oracle-jdbc.version}</version> 
      <scope>test</scope> 
     </dependency> 

     <dependency> 
      <groupId>org.easymock</groupId> 
      <artifactId>easymock</artifactId> 
      <version>${easymock.version}</version> 
      <scope>test</scope> 
     </dependency> 

    </dependencies> 

</project> 

और बराबर चींटी फ़ाइल:

<project name="persist" > 

    <import file="../build/common-build.xml" /> 


    <path id="compile.classpath.main"> 
     <pathelement location="${common.jar}" /> 
     <pathelement location="${domain.jar}" /> 
     <pathelement location="${hibernate.jar}" /> 
     <pathelement location="${commons-lang.jar}" /> 
     <pathelement location="${spring.jar}" /> 
    </path> 


    <path id="compile.classpath.test"> 
     <pathelement location="${classes.dir.main}" /> 
     <pathelement location="${testng.jar}" /> 
     <pathelement location="${dbunit.jar}" /> 
     <pathelement location="${easymock.jar}" /> 
     <pathelement location="${commons-dbcp.jar}" /> 
     <pathelement location="${oracle-jdbc.jar}" /> 
     <path refid="compile.classpath.main" /> 
    </path> 


    <path id="runtime.classpath.test"> 
     <pathelement location="${classes.dir.test}" /> 
     <path refid="compile.classpath.test" /> 
    </path> 


</project> 

tobrien उसके उदाहरण का इस्तेमाल किया दिखाने के लिए किया है कि Maven निर्मित सम्मेलनों लेकिन यह जरूरी नहीं कि आप कम एक्सएमएल लिखना समाप्त करते हैं। मैंने विपरीत होने के विपरीत पाया है। Pom.xml build.xml से 3 गुना लंबा है और यह सम्मेलनों से भटकने के बिना है। असल में, मेरे मेवेन उदाहरण को अतिरिक्त 54 लाइनों के बिना दिखाया गया है जिन्हें प्लगइन कॉन्फ़िगर करने की आवश्यकता थी। वह pom.xml एक साधारण परियोजना के लिए है। एक्सएमएल वास्तव में बढ़ती जा रही है जब आप अतिरिक्त आवश्यकताओं में जोड़ना शुरू करते हैं, जो कई परियोजनाओं के लिए सामान्य से बाहर नहीं है।

लेकिन तुम चींटी बताने के लिए

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

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

जटिलता

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

जब चींटी, एक Maven परियोजना पर निर्माण पुरुष अधिक समय बिताना होगा के साथ तुलना में:

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

इसके विपरीत:

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

परिचित

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

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