2009-01-06 17 views
36

स्कैटर किए बिना मेवेन प्रोजेक्ट्स का पदानुक्रम यदि आप एक ही संस्करण संख्या वाले कई कलाकृतियों वाली परियोजना के लिए Maven2 का निर्माण प्रणाली के रूप में उपयोग करते हैं, तो आपके पास सभी pom.xml में बिखरे हुए परिणामी निर्माण का संस्करण है। उनमें से कई में भी दो बार - आर्टेफैक्ट के संस्करण टैग में और माता-पिता के संस्करण टैग में। इस प्रकार, आपको प्रत्येक संस्करण स्विच पर सभी pom.xml के नए संस्करणों को बदलना और जांचना होगा। यह कुछ हद तक परेशान है, खासकर यदि आपको कई बग फिक्सिंग और समांतर में एक विकास संस्करण के लिए कोड करना है। क्या उसके आस-पास कोई रास्ता है?संस्करण संख्या

वर्गीकरण: मेरा प्रश्न प्रत्येक स्रोत pom.xml के कई संस्करणों के बारे में है जो आपको अपने स्रोत नियंत्रण प्रणाली में समय के साथ मिलता है जो केवल पोम के संस्करण संख्या और/या मूल पोम के संस्करण संख्या से भिन्न होता है। आदर्श रूप में, जब भी आप निर्भरता या कुछ जोड़ते हैं तो आपको केवल पोम को बदलने की आवश्यकता होनी चाहिए।

उदाहरण के लिए आपके पास कलाकृतियों foo-pom (सभी के लिए मूल पोम), foobar-jar, foobaz-jar और foo-war के साथ एक प्रोजेक्ट है। पहली रिलीज में संस्करण 1.0 है - जो प्रत्येक pom.xml में दिखाई देता है। दूसरी रिलीज में संस्करण 1.1 है - जो प्रत्येक pom.xml में फिर से दिखाई देता है। तो आपको हर pom.xml को बदलना होगा - यदि आप जितनी बार चाहें उतनी बार रिलीज़ करते हैं तो यह परेशान होता है।

अद्यतन: यदि आपको लगता है कि यह महत्वपूर्ण है: मूल संस्करण निर्दिष्ट करने के लिए पहले से ही विचार नहीं किया जा रहा है। कृपया maven JIRA issue पर जाएं और इसे और अधिक ध्यान देने के लिए वोट दें और आने वाली रिलीज में वृद्धि के रूप में जोड़े जाने की अधिक संभावना है। इसके लिए आपको एक जेआईआरए लॉगिन बनाना/बनाना होगा।

another Stackoverflow Question है जो मूल रूप से एक ही समस्या के बारे में है।

उत्तर

18

another StackOverflow thread that also covers this topic that you might want to look at है।

संक्षेप में, विरासत का उपयोग करते समय मूल संस्करण निर्दिष्ट करने के लिए नहीं है already being considered. Please go over to JIRA and give it a vote bump और अधिक ध्यान देने के लिए और आगामी रिलीज में वृद्धि के रूप में जोड़े जाने की अधिक संभावना है।

7

मेरी परियोजना पर, मुझे ऐसी समस्या है। मैं अपने माता-पिता में परिभाषित संस्करणों की संख्या को कम करने के लिए कुछ गुण है, जो प्रत्येक मॉड्यूल के संस्करणों के अनुरूप pom.xml:

<properties> 
    <project-version>1.0.0</project-version> 
    <!-- Same version than the parent for the module 'commons' --> 
    <project-commons-version>${project-version}</project-commons-version> 
    <!-- A specific version for the 'business' module --> 
    <project-business-version>1.0.1</project-business-version> 
    ... 

और फिर, प्रत्येक मॉड्यूल के pom.xml में, मैं इन गुणों का उपयोग करें। समस्या यह है कि मुझे इस pom.xml में माता-पिता के संस्करण को स्पष्ट रूप से इनपुट करना होगा। उदाहरण के लिए, अपने व्यवसाय pom.xml में, मेरे पास है:

<project> 
    <modelVersion>4.0.0</modelVersion> 
    <!-- I must indicate the version of the parent --> 
    <parent> 
    <groupId>my.project</groupId> 
    <artifactId>parent</artifactId> 
    <version>1.0.0</version> 
    </parent> 
    ... 
    <dependencies> 
    <!-- However, in my dependencies, I use directly the properties defined in the parent's pom.xml --> 
    <dependency> 
     <groupId>my.project</groupId> 
     <artifactId>project-persistence</artifactId> 
     <version>${project-persistence-version}</version> 
    </dependency> 

हालांकि, मैं वास्तव में सुझाव है कि आप release plugin कि आप के लिए सभी संस्करण संख्याओं को संशोधित करने का ख्याल रखना होगा करने के लिए एक नजर है।

+0

वह पैटर्न है जिसे हम भी उपयोग कर रहे हैं - रिलीज प्लगइन को छोड़कर। मैं सोच रहा था कि क्या आप किसी भी तरह से प्रत्येक pom.xml में मूल संस्करण डालने से बच सकते हैं। लेकिन ऐसा लगता है कि आपको स्रोत नियंत्रण में पोम के कई संस्करणों के साथ रहना है जो केवल मूल संस्करण से अलग है। –

+1

मुझे लगता है कि इस दृष्टिकोण को मेवेन संस्करण प्लग-इन के साथ पूरक किया जा सकता है: http://mojo.codehaus.org/versions-maven-plugin यह बाल परियोजनाओं में स्वचालित रूप से parent.version टैग को बढ़ा सकता है; संस्करण देखें: अद्यतन-बाल-मॉड्यूल लक्ष्य। – Dan

7

क्या यह article आपकी समस्या का समाधान प्रदान करता है?

विचार पूरे प्रोजेक्ट के लिए संस्करण संख्या को "संपत्ति" (पैन इरादा), माता-पिता पोम में घोषित करना है। अभिभावक पोम का अपना संस्करण संख्या तब तक कुछ भी हो सकता है जब तक यह "स्नैपशॉट" के साथ समाप्त होता है।

बाल मॉड्यूल का संस्करण $ {aversion} संपत्ति के माध्यम से निर्दिष्ट किया गया है। उनके माता-पिता के संस्करण के बच्चों का संदर्भ कठिन कोडित है। हालांकि, चूंकि अभिभावक पोम का संस्करण एक स्नैपशॉट है, इसलिए बाल मॉड्यूल पेरेंट पोम में बदलाव देखेंगे। विशेष रूप से, यदि अभिभावक पोम $ {aversion} के मान को बदलता है, तो बच्चे परिवर्तन देखेंगे।

टिप्पणियों के अनुसार एक सही समाधान नहीं है।

और रिलीज प्लगइन वास्तविक समस्या को हल नहीं करता है: विलय
पूरे स्थान पर संस्करण संख्या की अंतहीन प्रतियों का अर्थ है शाखाओं को एक साथ वापस लाने के दौरान कई संघर्ष।

नोट:

Maven 2.0.9 के साथ

(नवीनतम एक - अप्रैल 2008) मैं बस अलग-अलग मॉड्यूल से संस्करण तत्व को छोड़ते हुए किया गया है के रूप में वे अपने अभिभावकों से संस्करण प्राप्त कर लेगा। यह समूह आईडी के साथ भी काम करता है यदि आपके मॉड्यूल एक ही समूह आईडी को अपने माता-पिता के रूप में साझा करते हैं।

+2

वॉनसी सही है कि आप अपने पोम के समूह आईडी और artifactId को छोड़ सकते हैं अगर आप चाहते हैं कि वे माता-पिता के समान हों। लेकिन चुनौती अभी भी मौजूद है कि आपको विशेष रूप से एक बहुआयामी पदानुक्रमित निर्माण में भी अपने माता-पिता का संस्करण घोषित करना होगा। –

3

यह मैवेन के संभावित विस्तार के लिए एक विचार है जो समस्या को हल करेगा। वर्तमान में आपको pom.xml में आर्टिफैक्ट और पैरेंट पोम का संस्करण लिखना है।

<parent> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>my-parent</artifactId> 
    <version>2.0</version> 
    <relativePath>../my-parent</relativePath> 
</parent> 

यदि आप की अनुमति देने के दोनों माता पिता की है और इस पोम iff Maven के संस्करण की छोड़ते हुए रिश्तेदार पथ द्वारा माता-पिता पोम उपयोग करने में सक्षम है: वहां पहले से ही एक तरह से माता पिता पोम के लिए एक निरपेक्ष स्थान दे रहा है , आप कर चुके हैं। संस्करण केवल माता-पिता पोम में उल्लेख किया गया है और कहीं और नहीं।

+0

तुलना करें http://jira.codehaus.org/browse/MNG-1012 –

8

मैं जबकि एक बड़ी Maven 2.

मेरी राय में से बनाया प्रणाली पर काम कर इसी तरह की समस्याओं में चलाने की है, ठेठ बहु मॉड्यूल संरचना के नकारात्मक पक्ष यह है सभी मॉड्यूल एक ही संस्करण साझा करने के लिए वह यह है कि । यह वास्तव में कष्टप्रद है: भले ही आपकी अगली रिलीज में केवल foobar-jar में बगफिक्स शामिल है, तो आपको हर जगह वैश्विक संस्करण को बदलने की आवश्यकता है (इसे मैन्युअल रूप से या maven-release-plugin के साथ) और प्रत्येक घटक की एक नई रिलीज रोल करें। मेरे मामले में, मैंने विभिन्न WAR/EAR अनुप्रयोगों का निर्माण किया, इसलिए मेरा ग्राहक मुझसे पूछेगा कि मैंने app1 और app2 दोनों का नया संस्करण क्यों दिया, जब केवल app1 को प्रभावित किया जाना था।

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

मैंने दोनों दृष्टिकोणों को गठबंधन करने के तरीके के बारे में सोचा है: स्वतंत्र संस्करणों की लचीलापन, सिस्टम की वैश्विक समेकन को छोड़ दिए बिना। मैंने रोमांटैज के समान दृष्टिकोण की कोशिश की, और एक ही समस्या में भाग गया। अंत में, मैं इस विचार के साथ आया: http://out-println.blogspot.com/2008/10/maven-modules-with-independent-versions.html

इसे 'प्रयोगात्मक' के रूप में मानें, क्योंकि मुझे इसे अंत में रहने की कोशिश नहीं की गई थी (गैर-तकनीकी कारणों से)। लेकिन मुझे लगता है कि यह चाल करेगा।

+0

ब्लॉग लिंक मर चुका है, क्या आप कृपया एक नया लिंक प्रदान कर सकते हैं? –

0

maven issue हल होने तक यहां एक और हल्का कामकाज है। एक बड़ी परियोजना में हम अब pom.xml को संस्करण नियंत्रण में नहीं डालते हैं, लेकिन एक pom-template.xml जिसमें केवल संस्करण संख्या के लिए प्लेसहोल्डर शामिल है।संस्करण नियंत्रण से प्रोजेक्ट ट्री को अपडेट करने के बाद आपको एक छोटी चींटी स्क्रिप्ट चलाने की आवश्यकता है जो प्रत्येक निर्देशिका में वास्तविक pom.xml उत्पन्न करता है। यह कष्टप्रद है, लेकिन उन सभी परेशान पोम संस्करणों को स्थापित करने के मुकाबले कम परेशान है।

1

हमारे पास वास्तव में यह समस्या है। हमारे पास विभिन्न परियोजनाओं की एक बड़ी संख्या (लगभग 10) है जिनमें से कुछ एक-दूसरे पर निर्भर हैं। परियोजनाओं वाले फ़ोल्डर में परियोजनाओं के पूरे सेट के लिए एक पैरेंट पोम है। हर बार जब हमने एक नई शाखा बनाई, तो हमें माता-पिता के लिए < संस्करण> तत्व और < संस्करण> को बदलने के लिए प्रत्येक और प्रत्येक पोम फ़ाइल में जाना पड़ा, और यह सब संपादन परेशान था।

इस प्रश्न को पढ़ने के बाद और यहां जवाब मुझे एहसास हुआ कि स्थिति निराशाजनक थी। प्रत्येक प्रोजेक्ट < संस्करण> तत्व को पैरेंट पोम से प्राप्त कर सकता है ताकि एक को खत्म करना आसान हो, लेकिन हम स्पष्ट रूप से < संस्करण> < पैरेंट> के लिए प्राप्त नहीं कर सके।

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

<version>${currentVersion}</version> 

मैं क्यों इस काम करता है पता नहीं है:

<properties><currentVersion>2.6.1-SNAPSHOT</currentVersion></properties> 
तो बच्चे पोम फाइलों में

हम इस तरह माता-पिता संस्करण टैग घोषित । मैं नहीं देखता कि यह संस्करण संख्या निर्दिष्ट किए बिना सही पैरेंट पोम कैसे पा सकता है। लेकिन मेरे लिए (मेवेन संस्करण 1.5.0_22) यह काम कर रहा है।

+0

इसके बजाए, आप रिलीज प्लगइन का उपयोग करना चाहेंगे। यह आपको संस्करण संख्याओं को बदलने में मदद करेगा। – JohnnyK

+1

हां, जैकबिट, दो चीजों को छोड़कर। (1) हमारे पास हमारी रिलीज प्रक्रिया की अन्य विशिष्टताएं हैं जो रिलीज प्लगइन का उपयोग करना मुश्किल बनाती हैं, और (2) जैसा कि मैंने समझाया है, हमें अब समस्या नहीं है। – mcherm

+0

यह उत्तर क्यों कम किया गया है? यह एक ईश्वरीय समाधान है (माता-पिता में मेरे पास ' $ {version}' मेरे लिए यह काम कर रहा है – Tommaso

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