मेवेन मल्टी-मॉड्यूल प्रोजेक्ट स्ट्रक्चर

Question

मैं एक वितरित एप्लिकेशन का निर्माण कर रहा हूं जो फ्रंट-एंड (पढ़ें: वेब-फेस) HTTP एपीआई से आधारित है जो अंतर्निहित (पढ़ना: गैर-वेब-फेस) थ्रिफ्ट सर्विसेज में कॉल करता है।

एक उदाहरण के रूप में, मैं हो सकता है:

• प्रमाणीकरण सेवा
• कोर-सेवा ((प्रमाणीकरण के लिए कोड शामिल हैं) इस तरह के सेवा खोज और आरंभीकरण तर्क के रूप में उत्पन्न बचत स्रोतों और कुछ सामान्य कक्षाओं में शामिल है)

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

tl; डॉ -

यह एक मॉड्यूल (कोर-सेवा) के लिए एक आम निर्माण अभ्यास जो व्यक्तिगत रूप से अन्य में बनाया गया है और फिर एक Maven रेपो के लिए धक्का दिया (और फिर शामिल एक जार के रूप में है परियोजनाओं), या यह एक बहु-मॉड्यूल परियोजना करने के लिए इस मामले में बेहतर होगा?

Answer 1

व्यक्तिगत रूप से मैं बहु-मॉड्यूल परियोजनाओं से बचने की कोशिश करता हूं, यदि आप Maven Release Plugin का उपयोग कर रहे हैं, तो आप अपने सभी मॉड्यूल को एक साथ रिलीज़ करने में बंद कर दिए गए हैं।

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

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

तो, स्वतंत्र मॉड्यूल के साथ जाएं, लेकिन, यह महत्वपूर्ण बात है, प्रत्येक द्वारा उपयोग की जाने वाली एक आम 'निर्भरता' पोम बनाएं।

ए 'निर्भरता' पोम पोम एक है कि अपनी परियोजनाओं के सभी निर्भरता मानकीकरण और है कि उन निर्भरता के बजाय dependencyManagement अनुभाग dependencies खंड में निर्दिष्ट कर रहे हैं में अलग है (यह भी मानक प्लगइन config, आदि सेट)। यह आपके प्रोजेक्ट पोम्स को निर्भरता पोम को उनके माता-पिता के रूप में निर्दिष्ट करने की अनुमति देता है और उसके बाद उन निर्भरताओं को घोषित करता है जिन्हें उन्हें 'निर्भरता' पोम से उठाया जाता है और इस प्रकार आपकी परियोजनाओं में मानकीकृत किया जाता है।

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

Answer 2

मैं कहूंगा कि बहु-मॉड्यूल प्रोजेक्ट बेहतर है। भंडार डेवलपर्स में कोर सेवा रखने के मामले में संस्करणों की देखभाल करनी चाहिए। डेवलपर 1 को पुरानी सेवा की आवश्यकता है लेकिन डेवलपर 2 सेवा अपडेट करता है।

एकाधिक शाखाएं भी एक समस्या हो सकती हैं।

Answer 3

सिद्धांत रूप में आपकी परियोजनाओं को यथासंभव स्वतंत्र रूप से विकसित करना हमेशा बेहतर होता है। हालांकि यह तकनीकी एक के बजाय एक संगठनात्मक मुद्दा है। जब सब कुछ कहा जाता है और किया जाता है तो आपकी परियोजना संरचना आपके संगठन के अनुरूप होनी चाहिए।

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

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

नकारात्मकता यह है कि एक समान संरचना को बनाए रखना जटिल और समय लेने वाला है। हमने इन कार्यों को आंशिक रूप से स्वचालित करने के लिए बड़ी संख्या में स्क्रिप्ट विकसित की हैं। यह विशेष रूप से बोझिल है क्योंकि Maven release plugin सबवर्जन बाहरी के माध्यम से लगाए गए मॉड्यूल से निपटने में सक्षम नहीं है।

Answer 4

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

ओएसएस दुनिया में इसका एक मजबूत उदाहरण apache camel project है। उदाहरण के लिए, सभी बंडल घटक individual modules के रूप में मौजूद हैं जिन्हें आपकी परियोजना में अलग से शामिल किया जा सकता है, लेकिन ऊंट कोर वितरण के समान जीवन चक्र से बंधे हैं।

मेवेन मल्टी-मॉड्यूल बिल्ड कुछ सुविधाओं के लिए अनुमति देता है जब यह आपकी परियोजनाओं को सीआई में डालने या आईडीई में लोड करने के लिए नीचे आता है, लेकिन आम तौर पर बोलते हुए, यदि सभी व्यक्तिगत मॉड्यूल एक ही जीवन चक्र साझा नहीं करते हैं, तो एक मल्टी-मॉड्यूल प्रोजेक्ट एक महान फिट नहीं है