11
मैवेन के बहु मॉड्यूल प्रोजेक्ट के बारे में मेरा एक सामान्य प्रश्न है। कब और क्यों इसके लिए जाना है?बहु-मॉड्यूल मेवेन प्रोजेक्ट क्यों और कब बनाना है?
A
उत्तर
3
@Esko Luontola
विभाजन का जवाब कई मॉड्यूल में परियोजना उदाहरण के लिए उपयोगी है मॉड्यूल, अलग से तैनात किया जा करने की आवश्यकता है ..
गलत व्याख्या की जा सकती है। यदि आपके पास मॉड्यूल हैं जो अलग से तैनात किए जाएंगे, तो यह बिल्कुल विपरीत है। ऐसे मामले में, आपको कभी भी बहु-मॉड्यूल निर्माण नहीं करना चाहिए। यह सरल अलग मैवेन परियोजनाओं के माध्यम से किया जाना चाहिए।
बहु-मॉड्यूल निर्माण का विचार यह है कि यदि आपके पास मॉड्यूल हैं जो एक कान प्रोजेक्ट की तरह हैं जो आम तौर पर क्लाइंट, सर्वर, ईजेबी, युद्ध इत्यादि जैसे कई अन्य होते हैं। यह आमतौर पर बहु-मॉड्यूल के माध्यम से संभाला जाता है। निर्माण करें जिसका मतलब है कि सभी मॉड्यूल में एक ही संस्करण संख्या होती है लेकिन इसे अलग-अलग उपयोग किया जा सकता है और अन्य द्वारा उपयोग किया जा सकता है।
1
परियोजना को कई मॉड्यूल में विभाजित करना उपयोगी है उदाहरण के लिए यदि मॉड्यूल को अलग से तैनात करने की आवश्यकता है, या लाइब्रेरी के मामले में परियोजना के कुछ उपभोक्ताओं को कक्षाओं का केवल एक सबसेट चाहिए, या लाइब्रेरी के डेवलपर चाहते हैं सार्वजनिक एपीआई क्या है और निजी कार्यान्वयन क्या है के बीच स्पष्ट अंतर बनाओ। और बड़ी परियोजनाओं के साथ यह कोड को क्रम में रखना आसान बना सकता है, भले ही यह कोड तकनीकी रूप से एक ही मॉड्यूल में हो।
1
जिसमें मैं बहु मॉड्यूल Maven परियोजना का उपयोग कर की सिफारिश करेंगे कुछ और उपयोग के मामलों रहे हैं:
- आपका मॉड्यूल
का हिस्सा ही निर्भरता, इस मामले में आप मुख्य पोम में सभी निर्भरता निर्दिष्ट करेगा, और सभी मॉड्यूल इसका आनंद ले सकते हैं। (प्रत्येक मॉड्यूल के लिए समान निर्भरताओं के लिए निर्दिष्ट करने की आवश्यकता नहीं है।)
यदि आपको एक साथ कई परियोजनाओं पर संचालन करने की आवश्यकता है। (मैं इसे व्यक्तिगत रूप से उपयोग करता हूं), मैं अपनी सभी परियोजनाओं से एक पैकेज बनाता हूं, और इसे एक मूल्यवान को भेजता हूं, इसलिए मैं उन्हें मुख्य पोम का उपयोग करके बना देता हूं, और उन्हें अन्य मैवेन प्लगइन का उपयोग करके ज़िप फ़ाइल के रूप में पैकेज करता हूं।
3
ऐसा लगता है कि यह प्रश्न सामान्य रूप से सॉफ़्टवेयर के बारे में अधिक है। मेवेन ऐसा करने का एक ही तरीका है।
मैं से "Continuous Delivery", by Jez Humble
एक घटक क्या है कुछ लाइनें qoute होगा? यह सॉफ़्टवेयर, में एक बहुत अधिक अधिभारित शब्द है, इसलिए हम इसे यथासंभव स्पष्ट करने की कोशिश करेंगे कि इसका क्या अर्थ है। जब हम घटकों के बारे में बात करते हैं, तो हमारा मतलब है कि एक अच्छी तरह से परिभाषित एपीआई के साथ एक उचित रूप से बड़े पैमाने पर कोड संरचना, एक अच्छी तरह से परिभाषित एपीआई के साथ, संभावित रूप से किसी अन्य कार्यान्वयन के लिए स्वैप किया जा सकता है। घटक-आधारित सॉफ़्टवेयर सिस्टम इस तथ्य से अलग है कि कोडेबेस को अलग-अलग टुकड़ों में विभाजित किया गया है जो के माध्यम से व्यवहार प्रदान करते हैं, अन्य घटकों के साथ अच्छी तरह से परिभाषित, सीमित इंटरैक्शन। घटक-आधारित प्रणाली का एंटीथेसिस एक मोनोलिथिक सिस्टम है जिसमें स्पष्ट सीमाएं या तत्वों के बीच चिंताओं को अलग करना विभिन्न कार्यों के लिए ज़िम्मेदार है।मोनोलिथिक सिस्टम में आमतौर पर खराब encapsulation है, और तार्किक स्वतंत्र संरचनाओं के बीच तंग युग्मन डेमेटर के कानून को तोड़ता है।
...
एक घटक आधारित डिजाइन को रोजगार अक्सर पुन: उपयोग को प्रोत्साहित करने और इस तरह ढीला संयोजन के रूप में अच्छा वास्तु गुण के रूप में वर्णित किया गया है। यह सत्य है, लेकिन इसका एक और महत्वपूर्ण लाभ भी है: यह डेवलपर्स की बड़ी टीमों के सहयोग के लिए सबसे प्रभावी तरीकों में से एक है।
...
कई परियोजनाएं एक एकल संस्करण नियंत्रण भंडार और एक सरल तैनाती पाइप लाइन के साथ ठीक कर रहे हैं। हालांकि, कई परियोजनाएं कोड में एक अनजान सक्षम मोरस में विकसित हुई हैं क्योंकि किसी ने का निर्णय नहीं लिया है, जब ऐसा करने में सस्ता था तो अलग-अलग कंपोनेंट बनाएं। पर बिंदु जो छोटी परियोजनाएं बड़े पैमाने पर बदलती हैं तरल पदार्थ है और आपके ऊपर छीन लेगी।
...
अंत में, यह कोनवे की विधि, जिसमें कहा गया है कि "संगठनों जो डिजाइन प्रणालियों ध्यान देने योग्य है। । । डिज़ाइन तैयार करने के लिए बाध्य हैं जो इन संगठनों के संचार संरचनाओं की प्रतियां हैं। "4 इसलिए, उदाहरण के लिए, ओपन सोर्स प्रोजेक्ट्स जहां डेवलपर्स केवल ईमेल द्वारा संवाद करते हैं, कुछ इंटरफेस के साथ बहुत मॉड्यूलर होते हैं। एक छोटी, कोलोक्टेड टीम द्वारा विकसित एक उत्पाद कसकर युग्मित और मॉड्यूलर नहीं होगा। सावधान रहें कि आपने अपनी विकास टीम कैसे सेट की है-यह आपके एप्लिकेशन के आर्किटेक्चर को प्रभावित करेगा।
मुझे आश्चर्य है कि यह अंतिम कथन कितना स्पष्ट और सटीक है। और मैं दृढ़ता से उस पुस्तक की अनुशंसा करता हूं! :-)