6

मैं वर्तमान में एक बहु-मॉड्यूल मैवेन प्रोजेक्ट के मेवेन बिल्ड को अनुकूलित करने पर काम कर रहा हूं। परियोजना में लगभग 9 0 मेवेन मॉड्यूल शामिल हैं। आम तौर पर कुछ क्रॉस-कटिंग libs कोर बनाते हैं और फिर पूरे एप्लिकेशन को बनाने के लिए लगभग 15 "एप्लिकेशन मॉड्यूल" होते हैं (जिसे बाद में एक डब्ल्यूएआर में तैनात किया जाता है)एक बहु-मॉड्यूल मेवेन बनाना स्वतंत्र रूप से अलग-अलग मॉड्यूल का निर्माण और रिलीज़ करना?

अब सामान्य रूप से पूरी परियोजना में एक प्रमुख संस्करण "2.5" तो जब एक नई बड़ी रिलीज की जाती है तो सभी "एप्लिकेशन मॉड्यूल" में एक ही संस्करण "2.5.0" होता है। अब तक सब ठीक है।

यदि किसी मॉड्यूल में एक बग है जिसे ठीक करने या सुधारने की आवश्यकता है, तो उस "एप्लिकेशन मॉड्यूल" का एक नया संस्करण जारी किया जाना चाहिए। तो उदाहरण के लिए मॉड्यूल ए को एक बग फिक्स्ड मिला, फिर एजर संस्करण "2.5.1" में होना चाहिए जबकि शेष अभी भी "2.5.0" होना चाहिए।

माता पिता (2.5.0-SNAPSHOT - मॉड्यूल एक (2.5.1-स्नैपशॉट) - मॉड्यूल बी (2.5.0-स्नैपशॉट) - मॉड्यूल सी (2.5.2-स्नैपशॉट) - युद्ध (2.5। 3-स्नैपशॉट) < - अंत में 3, क्योंकि सी में 2 पुन: रिलीज़ और एक था और सादगी के लिए प्रत्येक मॉड्यूल रिलीज के बाद रिलीज़ किया गया था।

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

तो अब जब भी एक अद्यतन "एप्लिकेशन मॉड्यूल" तैयार होता है, तो हम मेवेन का उपयोग करते हैं उस मॉड्यूल की रिलीज करने के लिए रिलीज प्लगइन (हम एक मॉड्यूल जारी कर रहे हैं, पूरी परियोजना नहीं)। तो मान लें कि हम संस्करण 2.5.4 में मॉड्यूल ए जारी कर रहे हैं जिसके परिणामस्वरूप एजर को संस्करण 2.5.4 के रूप में तैनात किया जा रहा है और मॉड्यूल कोड को 2.5.5-एसएनएपीएसएचओटी में अपडेट करके परिष्करण किया जा रहा है।

ऐसा करने के बाद हमें मास्टर पोम में संस्करण को अपडेट करने की आवश्यकता है, इसलिए सभी मॉड्यूल सही संस्करण का संदर्भ जारी रखते हैं। जैसे ही सभी मॉड्यूल जारी कर रहे हैं,:

मास्टर पोम की dependencyManagement अनुभाग के लिए धन्यवाद, अगर मैं युद्ध मॉड्यूल का निर्माण, यह स्वचालित रूप से मॉड्यूल ए

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

इस दुविधा के लिए सबसे अच्छा समाधान क्या होगा?

मुझे निर्भरता प्रबंधन को एक अलग पोम में आउटसोर्स करने का एक विचार था, जिसे "आयात" दायरे का उपयोग करके मास्टर पोम्स निर्भरता प्रबंधन में आयात किया जाता है।

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

सहायता बहुत सराहना,

क्रिस

उत्तर

1

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

विवरण: https://dev.c-ware.de/confluence/display/PUBLIC/Releasing+modules+of+a+multi-module+project+with+independent+version+numbers

जेनकींस प्लगइन का विवरण: प्लगइन का https://dev.c-ware.de/confluence/display/PUBLIC/Developing+a+Jenkins+Plugin+for+the+Maven+Release+Plugin

कोड: https://github.com/chrisdutz/jenkins-release-plugin

2

सबसे पहले, यह है कि संस्करण संख्याओं का एहसास करने के लिए महत्वपूर्ण है, जबकि निर्भरता प्रबंधन के लिए महत्वपूर्ण है, पूरी तरह से मनमाने ढंग से कर रहे हैं। कम से कम, संस्करण संख्या का रूप मनमाने ढंग से है (हाँ, मुझे the syntax for Maven version ranges पता है, जिसे मैंने कभी भी किसी के बारे में नहीं सुना है)। कुछ ओएसएस परियोजनाएं पूरी तरह से "पारंपरिक" संस्करण संख्याओं को छोड़ती हैं और केवल एसवीएन भंडार संस्करणों या संस्करण के लिए तिथियों का उपयोग करती हैं।

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

स्नैपशॉट निर्भरताओं का उपयोग करके रिलीज़ करना एक और समाधान है। आप ऐसा करने के लिए "अनुमानित" नहीं हैं, लेकिन स्नैपशॉट संस्करण को हार्ड कोडिंग से कुछ भी आपको रोक नहीं रहा है (जो अविश्वसनीय रूप से वर्बोज़ और टाइमस्टैम्प है)। अप्रत्याशित बिल्डों के दर्शक को छोड़कर कुछ भी नहीं, वैसे भी।

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

इस दृष्टिकोण में, आप इस प्रश्न में वर्णित संस्करण के भीतर वृद्धिशील रिलीज को अलग करने के लिए Maven Build Number plugin का लाभ उठाते हैं: Can I set the project version with a buildnumber-maven-plugin?

नोट करें कि आप केवल "अंतिम रिलीज" प्रोफ़ाइल में ऐसा करेंगे जो केवल आपके बिल्ड सर्वर (या आपके बिल्ड इंजीनियर द्वारा) द्वारा उपयोग किया जाता है।

Version Numbers plugin भी आपका मित्र है।

संस्करण 2.5.5-SNAPSHOT साथ
  1. प्रारंभ:

    अंतिम रिलीज कार्यप्रवाह निम्नलिखित की तरह कुछ होगा।

  2. mvn versions:set -DnewVersion 2.5.5
  3. अपनी रिलीज को कम करें और टैग करें (या एक शाखा बनाएं - जो भी आपकी रणनीति यहां है)।
  4. mvn deploy -Prelease जो आपकी "रिलीज प्रोफ़ाइल" को सक्रिय करता है जो आर्टिफैक्ट finalName पर बिल्ड नंबर जोड़ता है।
  5. mvn versions:set -DnewVersion 2.5.5-SNAPSHOT
  6. अपने "पोस्ट-रिलीज" संस्करण को प्रतिबद्ध करें।

संस्करण 2.5.6, 2.6.0 आदि में वृद्धि जब आपके पास वास्तव में "प्रमुख" रिलीज है।

शुभकामनाएं!

+0

हाय noahz, कि स्पष्टीकरण यह मदद की के लिए धन्यवाद। मुझे एहसास हुआ कि यह काम करेगा अगर मेरे मॉड्यूल में एक दूसरे के लिए निर्भरता नहीं होगी। दुर्भाग्य से वे करते हैं। मुझे एक और विचार था कि इस समस्या को कैसे हल किया जा सकता है और इसके साथ एक नया जवाब बनाया जा सकता है (इस तरह मोर टेक्स्ट लिख सकता है ;-)) –

0

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

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

अब रिलीज के लिए निम्न चरणों को करना होगा: - संस्करणों से संबंधित संस्करणों और संस्करणों को नए संस्करणों में अपडेट करें। - कमिट - टैग - रिहाई चलाएँ: रिहाई प्लगइन का लक्ष्य प्रदर्शन

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

कोई सुझाव, आपत्तियां, चीजें जिन्हें मैं भूल गया?

क्रिस

+0

"मैं दो मेवेन पोम कलाकृतियों" संस्करण-देव "और" संस्करण-रिले "बनाएगा जो एक निर्भरता प्रबंधन अनुभाग है जो देव और रिले संस्करणों को परिभाषित करता है। " - क्यों न केवल एक 'pom.xml' में अलग प्रोफ़ाइल के रूप में ऐसा करते हैं? या इससे भी बेहतर, अपने निर्भरता संस्करणों को उन गुणों के साथ परिभाषित करें जो 'देव' और 'रिलीज' प्रोफाइल में सेट हैं? – noahlz

+0

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

संबंधित मुद्दे