मेवेन में बाल मॉड्यूल के संस्करण को कैसे अपडेट करें?

Question

बाल मॉड्यूल के संस्करण को कैसे अपडेट करें? इस तरह के बहुत सारे स्टैकओवरफ्लो प्रश्न हैं लेकिन मैं इस सटीक परिदृश्य में फिट नहीं ढूंढ पा रहा था ... अगर यह एक डुप्लिकेट है तो प्यार होगा।

निम्नलिखित परियोजना पर विचार करें।

parent 
    --mod1 
    --mod2 

एक देव रिलीज चक्र की शुरुआत में मुझे उसी संस्करण में अभिभावक और मॉड्यूल को अपडेट करने की आवश्यकता है। यदि माता-पिता और मॉड्यूल का संस्करण रिलीज के दौरान समान रहता है तो मैं मॉड्यूल से <version> टैग को छोड़ दूंगा और देव चक्र को बंद करने के लिए versions:set -DnewVersion=1.1.1 निष्पादित करूंगा। लेकिन जैसा कि यह पता चला है कि मॉड्यूल एक ही संस्करण के साथ चक्र को समाप्त नहीं करते हैं। चूंकि बग और फिक्स केवल उन मॉड्यूल को बग के साथ पूरा करते हैं और ऐसे अपडेट होते हैं। उदाहरण के लिए अभिभावक और mod2 संस्करण 1.1.1-RC1 पर हो सकता है, लेकिन mod1 1.1.1-RC2 पर हो सकता है।

जैसे मैं की जरूरत है:
1) स्वतंत्र रूप से प्रत्येक मॉड्यूल संस्करण ट्रैक करने के लिए मॉड्यूल में एक <version> टैग शामिल करें।

2) यदि mod2 को निर्भरता के रूप में mod1 की आवश्यकता है तो मुझे यह सुनिश्चित करने की आवश्यकता है कि mod2 mod1 का नवीनतम संस्करण संदर्भित करता है।

इससे निम्नलिखित दो प्रश्न होते हैं।

1) चक्र की शुरुआत में मैं एक मैवेन कमांड में उसी संस्करण में अभिभावक और मॉड्यूल कैसे सेट कर सकता हूं? मैंने version:set -DnewVersion=1.1.1 की कोशिश की, लेकिन यह केवल सभी पीओएम में माता-पिता के संस्करण को अपडेट करता है लेकिन मॉड्यूल के संस्करण पर नहीं। मैंने -N versions:update-child-modules भी कोशिश की, लेकिन मुझे लगता है कि मैं इसे गलत इस्तेमाल कर रहा हूं क्योंकि यह कुछ भी नहीं करता है, बस सभी मॉड्यूल के लिए छोड़ दिया गया दिखाता है।

2) यह थोड़ा कठिन है और ऊपर आइटम 2 से मेल खाता है। मैं mod1 के संस्करण और mod2 के संदर्भ में mod1 के संस्करण दोनों को एक चरण में कैसे अपडेट करूं? मुझे पता है कि 2 चरणों में यह करने के लिए:

माता पिता पोम:

<properties> 
    <!-- update this manually if mod1's version no longer matches parent --> 
    <mod1.version>${project.version}</mod1.version> 
</properties> 

mod2 पोम:

<dependency> 
     <groupId>com.xxx</groupId> 
     <artifactId>mod1</artifactId> 
     <version>${mod1.version}</version> 
    </dependency> 

जब mod1 1.1.1-RC2 अप करने के लिए मुलाकात मैं माता पिता पोम को अद्यतन करने और इसे बदलने के लिए mod1 पीओएम। ये दो कदम हैं। वैसे भी इसे एक कदम में बदलने के लिए?

मेरा उदाहरण छोटा था लेकिन वास्तविक जीवन में कई मॉड्यूल हैं जो इस महत्वपूर्ण समय बचतकर्ता को बनाता है, साथ ही मैं उत्सुक हूं।

Answer 1

प्रश्न 1)

आवेदन जीवन चक्र और विज्ञप्ति प्रबंधन करने के लिए सबसे अच्छा तरीका है रिहाई प्लगइन का उपयोग करने के लिए है में मदद करता है।

जैसा कि आप जानते हैं, मैवेन दर्शन कॉन्फ़िगरेशन पर सम्मेलन है। मेवेन सम्मेलन स्नैपशॉट संस्करणों (जो एसएनएपीएसएचओटी के साथ समाप्त होता है) का उपयोग विकास के दौरान और रिलीज के लिए केवल एक गैर स्नैपशॉट संस्करण असाइन करना है।

कहें कि आप संस्करण 1.1.1 विकसित कर रहे हैं। विकास के दौरान, आप बस 1.1.1-स्नैपशॉट का उपयोग करें। मैवेन स्नैपशॉट के अपडेट का ख्याल रखेगा। यदि एक आर्टिफैक्ट रिपोजिटरी का उपयोग करते हैं, तो आप यह सुनिश्चित करने के लिए -U का उपयोग कर सकते हैं कि आपके पास स्नैपशॉट का अंतिम संस्करण हमेशा होता है।

रिलीज तैयार होने पर, रिलीज प्लगइन जेनरेट करता है और संस्करण 1.1.1 तैनात करता है और नए विकास संस्करण, जैसे 1.1.2-SNAPSHOT के साथ पीओएम अपडेट करता है।

मल्टीमुड्यूल परियोजनाओं के बारे में, दो परिदृश्य हैं: मॉड्यूल संबंधित हैं लेकिन स्वतंत्र (जैसे कई वेब अनुप्रयोग) या वे एक बड़े एप्लिकेशन या पुस्तकालय के मॉड्यूल हैं और वे संस्करण साझा करते हैं। आप बाद में रुचि रखते हैं।

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

<parent> 
    <groupId>com.mycompany.myproject</groupId> 
    <artifactId>myproject-parent</artifactId> 
    <version>1.1.1-SNAPSHOT</version> 
    <relativePath>../myproject-parent</relativePath> 
</parent> 
<artifactId>myproject-module1</artifactId> 

अब तुम सिर्फ रिहाई प्लगइन की मदद से माता-पिता का सही संस्करण की ओर इशारा करते बच्चों की देखभाल की जरूरत है।

बच्चों के बारे में जानने में सहायता के लिए, आपको बाद में दिखाए गए मॉड्यूल अनुभाग सहित अपने मूल पोम को रूट पोम बनाना चाहिए।

प्रश्न 2) मैं आम तौर पर सभी कलाकृतियों के सभी संस्करणों के साथ माता-पिता में संपत्ति घोषित करता हूं जिन्हें संदर्भित किया जा सकता है। यदि कई मॉड्यूल संस्करण साझा करते हैं, तो आपको केवल एक संपत्ति की आवश्यकता है।

<groupId>com.mycompany.myproject</groupId> 
<artifactId>myproject-parent</artifactId> 
<version>1.1.1-SNAPSHOT</version> 
<packaging>pom</packaging> 
<properties> 
    <myproject.version>1.1.1-SNAPSHOT</myproject.version> 
</properties> 

....... 

<modules> 
    <module>../myproject-module1</module> 
    ... 
</modules> 

बच्चे

<version>${myproject.version}</version> 

का उपयोग कर यह एक बहुत ही खराब व्यवहार का नवीनतम का उपयोग कर निर्भरता घोषित करने के लिए है अन्य मॉड्यूल देख सकते हैं: माता-पिता की तरह लग सकता है। मान लें कि आप संस्करण 1.1.1 के लिए ऐसा करते हैं। अब आप संस्करण 1.1.2-स्नैपशॉट के साथ काम कर रहे हैं और शायद आपके पास अपने स्थानीय रेपो में स्थापित इस संस्करण के साथ कलाकृतियों हैं।

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

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

संपादित करें:

मामला जब मॉड्यूल संस्करणों गठबंधन नहीं कर रहे हैं।

असल में दोनों परिदृश्य मिश्रित किए जा सकते हैं। आप उदाहरण के लिए, हो सकता है:

जनक

--- Component1

--- Component2

--- Component3

------ Comp3Module1

------ Como3Module2

------ Comp3Module3

जहां माता-पिता और तीन घटक संस्करण अलग हैं और घटक 3 के तीन मॉड्यूल पहले जैसा समझाया गया है, वही संस्करण साझा करते हैं।

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

प्रश्न 2) अनुशंसित दृष्टिकोण समान संस्करण साझा करने के मामले के लिए समझाया गया है, केवल इतना है कि आपको कई गुणों की आवश्यकता है। तरह माता-पिता देख सकते हैं:

<properties> 
    <myproject.group>com.mycompany.myproject</myproject.group> 
    <component1.version>1.1.1-RC1</component1.version> 
    <component2.version>1.1.1-RC2</component2.version> 
    <component3.version>2.0.0</component3.version> 
<properties> 

तो फिर तुम माता पिता में संस्करण प्रबंधन को केंद्रीकृत करने निर्भरता प्रबंधन का उपयोग कर सकते हैं।

उदाहरण के लिए, माता पिता पोम में,

<dependencyManagement> 
    <dependencies> 
     <dependency> 
     <groupId>${myproject.group}</groupId> 
     <artifactId>component1</artifactId> 
     <version>${component1.version}</version> 
     </dependency> 
     <dependency> 
     <groupId>${myproject.group}</groupId> 
     <artifactId>component2</artifactId> 
     <version>${component2.version}</version> 
     <type>war</type> 
     </dependency> 
     <dependency> 
     <groupId>${myproject.group}</groupId> 
     <artifactId>comp3module1</artifactId> 
     <version>${component3.version}</version> 
     <type>ejb</type> 
     </dependency> 
     <dependency> 
     <groupId>${myproject.group}</groupId> 
     <artifactId>comp3module1</artifactId> 
     <version>${component3.version}</version> 
     <type>ejb-client</type> 
     </dependency> 
     <dependency> 
     <groupId>${myproject.group}</groupId> 
     <artifactId>comp3module2</artifactId> 
     <version>${component3.version}</version> 
     <type>war</version> 
     </dependency> 
    </dependencies> 
</dependencyManagement> 

अब, किसी अन्य मॉड्यूल से किसी भी मॉड्यूल को संदर्भित करने के लिए, यह के रूप में आसान है के रूप में:

<dependency> 
    <groupId>${myproject.group}</groupId> 
    <artifactId>component1</artifactId> 
</dependency> 
<dependency> 
    <groupId>${myproject.group}</groupId> 
    <artifactId>comp3module1</artifactId> 
    <type>ejb-client</type> 
</dependency> 

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

Answer 2

1) मैंने संस्करण को भी आजमाया है: अतीत में सेट किया गया है, लेकिन इसे सही तरीके से काम नहीं मिला। यह रिलीज के रूप में एक ही प्रक्रिया कर रहा है: तैयार है, लेकिन यह वास्तव में नहीं करता है। तो आप कोशिश कर सकते हैं mvn release:prepare -DautoVersionSubmodules -DdryRun। यह रिपो में कुछ भी जांच किए बिना और कोई टैग किए बिना सभी अपडेट करना है।

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

https://github.com/ClearTK/cleartk/tree/master/consistent-versions-plugin

जबकि इस तरह के एक प्लगइन अद्यतन आपके द्वारा अनुरोध किए नहीं होगा, यह कम से कम आप को सूचित करना चाहिए जब नई जानकारी जरूरी हैं। अपनी समस्या को वास्तव में ठीक करने के लिए, आप एक ही रूट का पालन करने पर विचार कर सकते हैं जैसे कि ClearTK ने किया था और अपनी खुद की मेवेन प्लगइन को कार्यान्वित किया था (या आप जो करते हैं, वह साफ़ करते हैं जो अंततः समाप्त हो गया है: एक सिंक किए गए रिलीज चक्र पर स्विच करना;))

Answer 3

ठीक है यह है मैं किसके साथ आया था। यह इस continuous-releasing-of-maven-artifacts आलेख पर आधारित है।

जनक पोम:

<groupId>com.xyz</groupId> 
    <artifactId>Module4</artifactId> 
    <packaging>jar</packaging> 
    <version>${Module4.version}</version> 

    <parent> 
     <groupId>com.xyz</groupId> 
     <artifactId>ParentProject</artifactId> 
     <version>1.0</version> 
    </parent> 

    <dependencies> 
     <dependency> 
      <groupId>com.xyz</groupId> 
      <artifactId>Module1</artifactId> 
      <version>${Module1.version}</version> 
     </dependency> 
     <dependency> 
      <groupId>com.xyz</groupId> 
      <artifactId>Module2</artifactId> 
      <version>${Module2.version}</version> 
     </dependency> 
     <dependency> 
      <groupId>com.xyz</groupId> 
      <artifactId>Module3</artifactId> 
      <version>${Module3.version}</version> 
      <type>jar</type> 
     </dependency> 
    <dependencies> 

1) चक्र की शुरुआत में मैं में माता पिता और एक ही संस्करण के लिए मॉड्यूल कैसे कर सकते सेट:

अंतर परियोजना निर्भरता के साथ

<properties> 
    <!-- versions of modules --> 
    <main.version>1.0</main.version> 
    <revision>SNAPSHOT</revision> <!-- default revision --> 
    <Module1.revision>${revision}</Module1.revision> 
    <Module2.revision>${revision}</Module2.revision> 
    <Module3.revision>${revision}</Module3.revision> 
    <Module4.revision>${revision}</Module4.revision> 
    <Module5.revision>${revision}</Module5.revision> 
    <Module1.version>${main.version}-${Module1.revision}</Module1.version> 
    <Module2.version>${main.version}-${Module2.revision}</Module2.version> 
    <Module3.version>${main.version}-${Module3.revision}</Module3.version> 
    <Module4.version>${main.version}-${Module4.revision}</Module4.version> 
    <Module5.version>${main.version}-${Module5.revision}</Module5.version> 
</properties> 

नमूना बच्चे पोम एक मेवेन कमांड?

अब आपको इसकी आवश्यकता नहीं है। अभिभावक पीओएम एक ही संस्करण में रह सकता है, केवल माता-पिता पीओएम बदलता है तो बदल रहा है। इस मामले में आप mvn version:set -DnewVersion=1.1.1 का उपयोग कर सकते हैं। लेकिन आपको इस दृष्टिकोण की आवश्यकता नहीं है।

इसके बजाय आप संपत्ति main.version का उपयोग कर संस्करण को गतिशील रूप से सेट कर सकते हैं। जैसे mvn clean deploy -Dmain.version=1.1.1 इसके अलावा, संस्करण संख्या के गतिशील गुजरने के लिए, आप डिफ़ॉल्ट main.version संपत्ति को छोड़ सकते हैं जिसे मैंने उपरोक्त मेरे मूल पीओएम में शामिल किया था।

2) मैं mod1 के संस्करण और mod2 के संदर्भ को mod1 के संस्करण को एक चरण में कैसे अपडेट करूं?

यह मूल रूप से संशोधनों को प्रबंधित करने के तरीके को उबालता है। अगर मैं mvn कमांड में revision प्रॉपर्टी सेट नहीं करता हूं, तो सभी मॉड्यूल संशोधन के रूप में SNAPSHOT का उपयोग करेंगे। अगर मैंने revision प्रॉपर्टी को RC1 पर सेट किया है तो सभी मॉड्यूल उस संशोधन को प्राप्त करेंगे। इसके अलावा, अगर मैंने revision से RC1 पर सेट किया है लेकिन Module4.revision से RC2 पर मॉड्यूल 4 आरसी 2 प्राप्त करता है और अन्य सभी मॉड्यूल आरसी 1 प्राप्त करते हैं। यह ग्राहकों को प्रति मॉड्यूल आधार पर गतिशील संशोधन करने का अनुरोध करता है।

• mvn clean deploy -Dmain.version=1.1.1 संस्करण 1.1.1-SNAPSHOT पर सेट करता है सभी मॉड्यूल:

  कुछ उदाहरण हैं।

• mvn clean deploy -Dmain.version=1.1.1 -Drevision=RC1 सभी मॉड्यूल को संस्करण 1.1.1-RC1 पर सेट करता है।
• mvn clean deploy -Dmain.version=1.1.1 -Drevision=RC1 -DModule4.revision=RC2 संस्करण 1.1.1-RC1 पर मॉड्यूल 4 को छोड़कर सभी मॉड्यूल सेट करता है जो संस्करण 1.1.1-RC2 पर सेट है।

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

Answer 4

1) के रूप में @rec कहा, Maven रिहाई प्लगइन चाल

$ mvn release:prepare -DautoVersionSubmodules=true 
$ mvn release:perform 

2) आप की तरह mod1 को mod2 पर निर्भरता को परिभाषित कर सकते हैं करना होगा:

<dependency> 
    <groupId>com.xxx</groupId> 
    <artifactId>mod1</artifactId> 
    <version>LATEST</version> 
</dependency> 

और जानकारी: How do I tell Maven to use the latest version of a dependency?

मैंने दोनों समाधानों का परीक्षण किया और यह काम करता है! आशा है कि यह आप :)