मैं लोगों को मेवेन का उपयोग करने या उपयोग करने के कारणों को जानना चाहता हूं। हम अपने सभी बिल्डों को मेवेन 2 में स्विच करने जा रहे हैं और इसके साथ ज्यादा अनुभव नहीं करना है।मेवेन का उपयोग करने के फायदे/नुकसान क्या हैं?
क्या Maven 2, की तरह सामान का उपयोग कर के लाभ/नुकसान कर रहे हैं:
धन्यवाद!
मैंने पिछले 4 वर्षों में मैंने जो भी परियोजना का सामना किया है, उसमें मैवेन का उपयोग किया है, निजी निजी परियोजनाओं से बड़े उद्यमों के दर्जनों मॉड्यूल परियोजनाओं तक और मैंने कभी कभी मैवेन का उपयोग करके खेद नहीं किया है।
मैं मानक जावा जार/युद्ध/EAR परियोजनाओं से कुछ भी/आकाशवाणी क्षुधा और लिनक्स RPM के Maven का उपयोग कर, या तो Antrun या GMaven को सौंपने जब कोई Maven प्लगइन किसी परिस्थिति के लिए उपलब्ध था फ्लेक्स के लिए निर्माण किया है।
मानक मेवेन लाइफसाइकिल की शक्ति और आराम कोड जनरेशन, दस्तावेज़ीकरण, कोड मीट्रिक इत्यादि के लिए उपलब्ध प्लगइन की बहुतायत के साथ संयुक्त है जो आम तौर पर उपयोग करने में आसान है, जावा निर्माण प्रणाली के लिए मेवेन एकमात्र असली विकल्प बनाता है।
आगे बढ़ें और इसे दबाएं, लेकिन जब तक आप कुछ बेहतर खोज नहीं लेते, मैं इसका उपयोग जारी रखूंगा।
मैंने मैवेन के साथ शुरुआत की और मैं इसके साथ रहूंगा। जब मैं मैवेन के साथ एक परियोजना का निर्माण करता हूं तो मुझे कभी भी पुस्तकालयों, गलत पुस्तकालय संस्करणों के साथ समस्या नहीं होती है ... यह संकलित करता है, यह चलता है।
पुस्तकालय अपग्रेड सरल है (चींटी की तरह नहीं)।
मेवेन कई उपयोगी प्लगइन प्रदान करता है। मैं हडसन पर कार्यक्षमता परीक्षण चलाने के लिए मेवेन का उपयोग करता हूं - यह मेरे प्रोजेक्ट का नवीनतम संस्करण डाउनलोड करता है, एम्बेडेड डेटाबेस शुरू करता है, डब्यूनिट डेटासेट इंजेक्ट करता है, जेटी पर एप्लिकेशन तैनात करता है, परीक्षण चलाता है, परीक्षण परिणाम प्रस्तुत करता है।
एक चीज जो मुझे पसंद नहीं है वह सब कुछ एक फाइल में रखना है। तो मैं न केवल एक्सएमएल का उपयोग विन्यास निर्दिष्ट करना चाहता हूं।
मेवेन का उपयोग करने का बड़ा लाभ इसकी भंडार संरचना है। यह तृतीय पक्ष पुस्तकालयों के साझाकरण के लिए मानक प्रोटोकॉल को बढ़ावा देता है और टीमों को एक ही स्रोत कोड भंडार (मॉड्यूलर बिल्ड) में सबकुछ जांचने के लिए मजबूर किए बिना अधिक प्रभावी ढंग से सहयोग करने में सक्षम बनाता है।
भंडार प्रबंधकों स्वतंत्र रूप से उपलब्ध हैं और मैं निम्न में से एक को स्थापित करने की सलाह देते हैं:
अच्छी खबर यह है कि आप नहीं कर रहे हैं है मेवेन इंफ्रास्ट्रक्चर होने के लाभों को लागू करने के लिए मेवेन का उपयोग करके अपना कोड बनाने के लिए मजबूर होना पड़ा।
मैं बचाव के लिए विरासत के बिना "ग्रीन फील्ड" परियोजनाओं के लिए मेवेन की सलाह देता हूं। एक परियोजना की शुरुआत आम तौर पर एक नई तकनीक शुरू करने का सबसे अच्छा समय है और मेवेन का उपयोग करने के लाभ अच्छी तरह से प्रलेखित हैं। उच्च रोशनी एक मानक निर्माण प्रक्रिया और तृतीय पक्ष प्लगइन्स की एक संपत्ति है।
एएनटी परियोजनाओं को मेवेन का उपयोग करके टीमों के साथ अंतर-संचालन के लिए फिर से इंजीनियर किया जा सकता है। ivy प्लगइन, ठीक से लागू किया गया है, वास्तव में एएनटी निर्माण प्रक्रिया को सरल बना सकता है। Ivy मैवेन रिपोजिटरी से निर्भरताओं को डाउनलोड करके और बाद में बिल्ड कलाकृतियों को प्रकाशित करके प्रोजेक्ट के क्लासपाथ को प्रबंधित करने में सक्षम है (बस एक मेवेन "तैनाती की तरह)।
अंत में ivy अन्य निर्माण उपकरणों में एम्बेड किया गया है। उदाहरण Gradle, simple-build-tool और Grails जैसे विकास प्रणालियों जैसे नए निर्माण उपकरण हैं। तो एंटरप्राइज़ मेवेन रिपोजिटरी के उपयोग को गले लगाएं और प्रोजेक्ट टीम के लिए उपयुक्त बिल्ड टूल चुनें।
मैं मार्क से सहमत हूं कि यह ग्रीनफील्ड परियोजनाओं के लिए बहुत अच्छा है। इसे प्राप्त करने और अपने विकास के माहौल में चलने के लिए एक ओवरहेड है, लेकिन यह इसके लायक है।
मैं जोड़ सकता हूं कि मेवेन का उपयोग करने के लिए एक संभावित खतरा यह है कि यदि आप एक बड़ी परियोजना पर काम कर रहे हैं, तो भंडार में जार को बनाए रखना मुश्किल हो सकता है। आप संभावित रूप से अपने POM.xml में जार के कई अलग-अलग संस्करणों का उपयोग कर समाप्त कर सकते हैं।
किसी भी परियोजना के साथ, सुनिश्चित करें कि आपके कोड बेस में विभिन्न जार लाने के लिए आपके पास अच्छी नीतियां और प्रक्रियाएं हैं। इन जारों में अलग-अलग लाइसेंस हो सकते हैं जो आपके कोड बेस को ओपन सोर्स वर्ल्ड में बेनकाब कर सकते हैं। सुनिश्चित करें कि इन लाइसेंसों की समीक्षा आपके द्वारा की जाती है।
मैवेन ने एक विशिष्ट समस्या हल की जो निर्भरता प्रबंधन को प्रभावशाली ढंग से करना था जब कोई नहीं था, या आइवी के साथ एक समानता थी। निजी तौर पर काम के बड़े बहु परियोजना कार्यक्रमों के लिए, जल्दी या बाद में, आपको _effective POM_ को देखना होगा और यही वह जगह है जहां मुझे लगता है कि मैवेन अप्रबंधनीय या प्रबंधित करने में मुश्किल हो जाता है ... जब तक आप शुरुआत से अनुशासित नहीं होते हैं। यही कारण है कि _that_ परिप्रेक्ष्य से मेरे लिए ग्रैडल अधिक उपयोगकर्ता के अनुकूल है, लेटर्स कोर ताकत के कारण मेवेन से दूर नहीं है, और जब जटिलता की बात आती है तो यह अधिक प्रबंधनीय होता है। हालांकि यह आप पर निर्भर है। – Beezer
मेवेन शानदार है!
मैं किसी विशेष क्रम में Maven की मेरी शीर्ष कुछ लाभ हैं के रूप में मैं चाहूँगा के रूप में ज्यादा समय गेय मोम की जरूरत नहीं है, लेकिन यहां:
डाउनसाइड्स के संदर्भ में, अक्सर यह कहा जाता है कि आप मेवेन डिफ़ॉल्ट और सम्मेलनों को स्वीकार करने से बेहतर हैं, और आदर्श रूप से इसे ग्रीनफील्ड परियोजना के शुरू में उपयोग करना शुरू कर देते हैं। यदि आप अपने पीओएम में एक्सएमएल कॉन्फ़िगर करने में समय बचाने के लिए चाहते हैं तो मैं इसके साथ एक डिग्री से सहमत हूं।
मैं वास्तव में एक उपकरण उत्साह नहीं हूं, लेकिन मेवेन से पहले मेक एंड एंट का उपयोग करने के बाद, मैं वास्तव में मेवेन को अपनाने के लिए एक भी नकारात्मक पक्ष नहीं देख सकता। यह एक गुणवत्ता उपकरण और एक वास्तविक समय बचतकर्ता है।
अब तक मुझे यह पसंद नहीं है। जब मैं मैवेन का उपयोग करता हूं तो एक परियोजना के लिए बिल्ड टाइम नाटकीय रूप से चला जाता है। बस ग्रहण पर कई एमएस से दूसरे तक, सबसे सरल मेवेन प्रोजेक्ट के लिए 30 सेकंड से अधिक तक।
यह देखते हुए कि इस तरह के बहुत से लोग मुझे कुछ गलत कर रहे हैं, लेकिन अब तक मुझे यह पता नहीं लगाया जा सकता है कि मेवेन आधारित परियोजना बनाने में उम्र क्यों लगती है।
मैं पूरी तरह से सहमत हूं। पॉलीग्लोट मेवेन के साथ आपको अब xml का उपयोग करने की आवश्यकता नहीं है, जो मेरी राय में मैवेन के डाउनसाइड्स में से एक है। जटिल परियोजनाओं के लिए पोम जल्दी से बहुत बड़ा हो जाता है। दूसरी तरफ यदि आप एम 2 ग्रहण द्वारा प्रदान किए गए एक पोम संपादक का उपयोग कर रहे हैं तो आपको किसी भी तरह से सीधे इसके मामलों से निपटने की ज़रूरत नहीं है। फिर भी पॉलीग्लोट मेवेन नियम :) –