Maven बदल कलाकृतियों केवल

Question

मैं Maven 2.2 का उपयोग कर रहा गठजोड़ के साथ नियोजित 1.4.0

चलो कहते हैं कि मैं (इसी संस्करणों के साथ) इस तरह की एक पोम-संरचना है

parentproj, v1.0.1 
- childproj1, v1.0.2 
- childproj2, v1.0.7 

childproj1 और childproj2 अलग प्रतिनिधित्व करते हैं आवेदन के कुछ हिस्सों (जैसे गुई और बैकएंड) और मैं अपने संस्करणों को अलग रखने में सक्षम होना चाहता हूं ताकि मैं गुई के नए संस्करण को जारी किए बिना बैकएंड का एक नया संस्करण जारी कर सकूं।

अब, Nexus के लिए यह सुविधाजनक हो सकता है इस संरचना को तैनात करने के लिए जाना parentproj और कहने के लिए

mvn तैनात -DperformRelease = सच

जो नेक्सस realease के भंडार के लिए सभी कलाकृतियों को तैनात करेगा । यह ठीक काम करता है पहली बार मैं यह तैनात है, लेकिन दूसरी बार मैं समस्याएं आ: मान लें कि मैं childproj1 के लिए एक अद्यतन बना देती हैं, ताकि हम अब निम्नलिखित संस्करण है कि:

parentproj, v1.0.1 
- childproj1, v1.0.3 
- childproj2, v1.0.7 

इस स्थिति में नेक्सस नहीं होगा मुझे पेरेंटप्रोज़ से एमवीएन तैनाती करने दें, क्योंकि इसमें 1.0.7 संस्करण में पहले से ही childproj2 की एक प्रति है। नेक्सस कहेंगे "संसाधन, अवैध अनुरोध: आईडी = 'रिलीज' के साथ रिपोजिटरी कलाकृतियों को अद्यतन करने की अनुमति नहीं देता है।" यह ठीक है, मैं गलती से मौजूदा संस्करणों को अद्यतन नहीं करना चाहता हूं।

लेकिन मुझे लगता है कि मैं क्या करना चाहता हूं कि मैवेन को कुछ ऐसा बताने में सक्षम होना चाहिए जैसे "केवल उन कलाकृतियों को तैनात करें जिनके संस्करण रिलीज रिपोजिटरी में पहले से मौजूद नहीं हैं"।

क्या ऐसा करने का कोई तरीका है, या क्या मुझे प्रत्येक प्रोजेक्ट को स्वयं ही तैनात करना होगा?

Answer 1

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

क्षमा करें, मैं जानता हूँ कि क्या यह आपके प्रश्न का एक विशिष्ट उत्तर नहीं है, लेकिन कम से कम मेरी टीम के मामले में, यह थोड़ा अलग ढंग से सोचने के लिए उपयोगी था

Answer 2

मेरा सुझाव है कि अगर आप को बनाए रखने की योजना है, का निर्माण , और स्वतंत्र रूप से मॉड्यूल को तैनात करते हैं, आपको प्रत्येक के लिए अलग सीआई और mvn deploy नौकरियां स्थापित करने पर विचार करना चाहिए। स्वतंत्र mvn deploy नौकरियां आपको वह व्यवहार देगा जो आप बॉक्स से बाहर खोज रहे हैं। इसका मतलब है कि इन मॉड्यूल के निर्माण और तैनाती के प्रयास के लिए एग्रीगेटर पोम (parentprj) का उपयोग नहीं करना है।

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

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

इस निर्णय को लेने का एक अच्छा तरीका खुद से पूछ रहा है "क्या किसी अन्य परियोजना/ऐप्स को इस मॉड्यूल को निर्भरता के रूप में संदर्भित करने की आवश्यकता होगी?"। यदि ऐसा है, तो इसे स्वतंत्र रूप से बनाने, संस्करण बनाने और इसे तैनात करने का सबसे अच्छा अभ्यास है। यदि नहीं, तो संस्करणों को मिलान करने के लिए मुझे कोई नुकसान नहीं दिख रहा है।

Answer 3

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

दो तरह की परियोजनाओं को सबसे अलग रखा जाता है। मूल परियोजना आमतौर पर अक्सर नहीं बदलती है और जब यह आमतौर पर उन सभी परियोजनाओं के नए संस्करणों को रिलीज़ करना सर्वोत्तम होता है जो इससे निर्भर होते हैं; एकत्रीकरण परियोजना का एकमात्र उद्देश्य परियोजनाओं के समूह का निर्माण करना है, इसलिए जब भी परियोजनाओं में से एक को रिलीज़ किया जाना चाहिए, तो इसकी रिलीज संख्या शायद बदलनी चाहिए।

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

Answer 4

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

एक आदर्श दुनिया में

• पोम
  शामिल होंगे। मॉड्यूल
  दोनों रिलीज संस्करण और स्नैपशॉट संस्करण दोनों। फ़ाइलों की एक परिभाषा, जो बदलती है, स्नैपशॉट संस्करण
  के उपयोग को उचित ठहराना।
  

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

• Maven रिएक्टर एक विकल्प होता रिहाई पुस्तकालय पता करने के लिए एक दिया मॉड्यूल अपनी रिहाई या स्नैपशॉट संस्करण में प्रयोग की जाने वाली है कि क्या दोनों निर्भरता पदानुक्रम और फ़ाइल में परिवर्तन की जानकारी (एससीएम अंतर) को पढ़ने के लिए ।

• रिलीज प्लगइन डिफ़ॉल्ट रूप से मॉड्यूल के रिलीज को छोड़ देगा जो अभी भी फ़ाइल परिवर्तनों और निर्भरता जानकारी के आधार पर उनके रिलीज़ संस्करण के साथ उपयोग किया जा सकता है।