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




maven-2 ant build-management (9)

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


Answers

मेवेन या चींटी? इस के लिए एक बहुत ही समान सवाल है, जो आपको अपने सवालों के जवाब देने में मदद कर सकता है।

मावेन क्या है? आधिकारिक साइट पर।

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


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

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

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


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

एक सरल तुलना

मैं आपको केवल इस विचार को स्पष्ट करने के लिए दिखा रहा हूं कि, सबसे बुनियादी स्तर पर, मेवेन ने अंतर्निहित सम्मेलन बनाए हैं। यहां एक साधारण चींटी बिल्ड फ़ाइल है:

<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 ", "से एक JAR बनाएँ। ... ", आदि। जहां चींटी को प्रक्रिया के बारे में स्पष्ट होना था, वहां मेवेन में कुछ" अंतर्निहित "था जो सिर्फ यह जानता था कि स्रोत कोड कहां था और इसे कैसे संसाधित किया जाना चाहिए।

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

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

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

जहां मेवेन ...

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

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

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

मेवेन बनाम चींटी से अधिक महत्वपूर्ण है

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

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


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

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

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

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

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

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


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


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

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

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

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

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


मेवेन एक फ्रेमवर्क है, चींटी एक टूलबॉक्स है

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

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

एक्सएमएल Verbosity

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

सबसे पहले, मेवेन फ़ाइल:

<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>

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

लेकिन आपको चींटी को बताना होगा कि क्या करना है

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

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

जटिलता

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

चींटी की तुलना में, मेवेन प्रोजेक्ट पर बिल्ड लड़का अधिक समय बिताएगा:

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

इसके विपरीत:

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

सुपरिचय

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

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


इस सवाल को साक्षात्कार में अक्सर पूछा जाता है कि क्या उम्मीदवार संग्रह कक्षाओं के सही उपयोग को समझता है और उपलब्ध वैकल्पिक समाधानों से अवगत है।

  1. हैश मैप क्लास लगभग हैशटेबल के बराबर है, सिवाय इसके कि यह सिंक्रनाइज़ नहीं है और नल की अनुमति देता है। (हैश मैप शून्य मूल्यों को कुंजी और मान के रूप में अनुमति देता है जबकि हैशटेबल नल की अनुमति नहीं देता है)।
  2. हैश मैप गारंटी नहीं देता है कि मानचित्र का क्रम समय के साथ स्थिर रहेगा।
  3. हैश मैप सिंक्रनाइज़ किया गया है जबकि हैशटेबल सिंक्रनाइज़ किया गया है।
  4. हैश मैप में इटरेटर असफल-सुरक्षित है, जबकि हैशटेबल के लिए गणनाकर्ता नहीं है और ConcurrentModificationException को फेंक देता है यदि कोई अन्य थ्रेड इटरेटर की अपनी निकासी () विधि को छोड़कर किसी भी तत्व को जोड़कर या हटाकर संरचनात्मक रूप से मानचित्र को संशोधित करता है। लेकिन यह गारंटीकृत व्यवहार नहीं है और सर्वोत्तम प्रयासों पर जेवीएम द्वारा किया जाएगा।

कुछ महत्वपूर्ण शर्तों पर ध्यान दें

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

हैश मैप द्वारा सिंक्रनाइज़ किया जा सकता है

Map m = Collections.synchronizeMap(hashMap);

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

नक्शा इंटरफेस





java maven-2 ant build-management