2008-08-27 19 views
623

मेवेन में, निर्भरता आमतौर पर इस तरह स्थापित की जाती है:मैं निर्भरता के नवीनतम संस्करण का उपयोग करने के लिए मेवेन को कैसे बताऊं?

<dependency> 
    <groupId>wonderful-inc</groupId> 
    <artifactId>dream-library</artifactId> 
    <version>1.2.3</version> 
</dependency> 

अब, यदि आप पुस्तकालयों के साथ काम कर रहे हैं जो अक्सर रिलीज़ होते हैं, तो लगातार < संस्करण > टैग को अपडेट करना कुछ परेशान हो सकता है। क्या नवीनतम उपलब्ध संस्करण (भंडार से) हमेशा उपयोग करने के लिए मेवेन को बताने का कोई तरीका है?

+134

बिल्डिंग पुनरुत्पादन के लिए मैं वास्तव में इस अभ्यास (और संस्करण श्रेणियों का उपयोग नहीं) की सिफारिश नहीं करता हूं। एक ऐसा निर्माण जो अचानक अज्ञात कारण के लिए असफल हो जाता है, मैन्युअल रूप से एक संस्करण संख्या को अद्यतन करने से कहीं ज्यादा परेशान होता है। –

+0

@ मार्टिन मैं xyz-SNAPSHOT सम्मेलन से अवगत हूं, लेकिन मैं उन पुस्तकालयों के बारे में सोच रहा था जो अंतिम संस्करणों में भंडार में जारी किए गए हैं (यानी सपने-पुस्तकालय-1.2.3.jar से सपने-पुस्तकालय-1.2.4 तक। जार, और इतने पर)। –

+8

@ पास्कल टिवेंट मैन्युअल रूप से एक पोम में रिलीज नंबर अपडेट करना एक दर्द है यदि आप निरंतर रिलीज कर रहे हैं।मैं इसे पाने के लिए एसएमएम प्लगइन के साथ संयुक्त संस्करण प्लगइन का उपयोग करता हूं (मेरा जवाब देखें)। –

उत्तर

618

नोट:

यह उत्तर केवल 2 Maven पर लागू होता है! 6 साल पहले उल्लिखित LATEST और RELEASE metaversions have been dropped in Maven 3 "for the sake of reproducible builds"। कृपया इस Maven 3 compliant solution देखें।


आप हमेशा नवीनतम संस्करण का उपयोग करना चाहते हैं, तो Maven दो कीवर्ड आप संस्करण पर्वतमाला के लिए एक विकल्प के रूप में उपयोग कर सकते है। आपको इन विकल्पों का ध्यान देखभाल के साथ उपयोग करना चाहिए क्योंकि आप अब प्लगइन/निर्भरताओं के नियंत्रण में नहीं हैं।

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

अधिक जानकारी के लिए POM Syntax section of the Maven book देखें।

  • एक वर्ग कोष्ठक ([ & ]) का अर्थ है "बंद" (सम्मिलित): या Dependency Version Ranges, जहां पर इस दस्तावेज़ नहीं देख।
  • एक कंस्ट्रैसिस (( & )) का अर्थ है "खुला" (अनन्य)।

यहां विभिन्न विकल्पों को चित्रित करने का एक उदाहरण दिया गया है। Maven भंडार में, com.foo:my-foo निम्नलिखित मेटाडाटा है:

<?xml version="1.0" encoding="UTF-8"?><metadata> 
    <groupId>com.foo</groupId> 
    <artifactId>my-foo</artifactId> 
    <version>2.0.0</version> 
    <versioning> 
    <release>1.1.1</release> 
    <versions> 
     <version>1.0</version> 
     <version>1.0.1</version> 
     <version>1.1</version> 
     <version>1.1.1</version> 
     <version>2.0.0</version> 
    </versions> 
    <lastUpdated>20090722140000</lastUpdated> 
    </versioning> 
</metadata> 

कि विरूपण साक्ष्य पर निर्भरता की आवश्यकता है, आप निम्नलिखित विकल्पों (अन्य version ranges निश्चित रूप से निर्दिष्ट किया जा सकता है, बस दिखा प्रासंगिक लोगों यहाँ):

एक सटीक संस्करण (घोषित हमेशा 1.0.1 हो जाएगी):

<version>[1.0.1]</version> 

एक स्पष्ट संस्करण (घोषित हमेशा 1.0.1 को हल करेंगे जब तक कि एक टक्कर होती है, जब Maven होगा एक मिलान संस्करण का चयन करें):

<version>1.0.1</version> 

सभी 1.x के लिए एक संस्करण सीमा घोषित (वर्तमान में 1.1.1 हो जाएगी):

<version>[1.0.0,2.0.0)</version> 

एक ओपन एंडेड संस्करण सीमा घोषित (2.0.0 हो जाएगी):

<version>[1.0.0,)</version> 

संस्करण घोषित रूप में नवीनतम (2.0.0 करने के लिए हल होगा) (Maven 3.x से हटा)

<version>LATEST</version> 

विज्ञप्ति के रूप में संस्करण घोषित (1.1.1 करने के लिए हल होगा) (Maven 3.x से हटा):

<version>RELEASE</version> 

ध्यान दें कि डिफ़ॉल्ट रूप से अपनी खुद की तैनाती Maven मेटाडाटा में "नवीनतम" प्रविष्टि अपडेट करेगा, लेकिन "रिलीज" एंट्री अपडेट करने के लिए, आपको Maven super POM से "रिलीज-प्रोफाइल" सक्रिय करने की आवश्यकता है। आप या तो "-Prelease प्रोफ़ाइल" के साथ ऐसा कर सकते हैं या "-DperformRelease = सच"


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

इसलिए आम तौर पर रिलीज़ में सटीक संस्करणों को परिभाषित करना एक अच्छा विचार है। Tim's answer अंक के रूप में, maven-versions-plugin निर्भरता संस्करणों को अपडेट करने के लिए एक आसान उपकरण है, विशेष रूप से versions:use-latest-versions और versions:use-latest-releases लक्ष्यों।

+72

हाय रिच! ऐसा लगता है कि रिलीज और नवीनतम संस्करण मार्कर हैं [अब मैवेन 3.x] में समर्थित नहीं हैं (https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.x कॉम्पैबिलिटी नॉट्स- प्लगइन मेटावर्जन रेसोल्यूशन)। –

+13

अगर मैं दस्तावेज को सही ढंग से –

+0

समझता हूं तो मुझे लगता है कि दस्तावेज़ को अधिकतम/रिलीज प्लगइन के लिए बहुत महत्वपूर्ण है जो तैनाती कार्यक्षमता प्रदान करता है, तो सामान्य बहिष्कार की बजाय प्लगइन पर लागू होता है। उदाहरण के लिए हम प्लगइन का उपयोग करते हैं जो हमारे सर्वर पर कलाकृतियों के नए संस्करण को तैनात करता है। यदि सर्वर बदल जाएंगे तो हम प्लगइन का नया संस्करण जारी करेंगे और इस प्लगइन का उपयोग करने वाली सभी परियोजनाओं को प्लगइन के नए संस्करण का उपयोग करने के लिए मैन्युअल रूप से अपडेट किया जाना चाहिए। – ATom

14

क्या आप संभवतः विकास संस्करणों के आधार पर विकास के दौरान बहुत कुछ बदल सकते हैं?

विकास रिलीज के संस्करण को बढ़ाने के बजाय, आप केवल एक स्नैपशॉट संस्करण का उपयोग कर सकते हैं जिसे आप आवश्यकतानुसार ओवरराइट करते हैं, जिसका अर्थ है कि आपको प्रत्येक मामूली परिवर्तन पर संस्करण टैग को बदलना नहीं होगा। जैसे 1.0-SNAPSHOT कुछ ...

लेकिन हो सकता है आप कुछ और हासिल करने की कोशिश कर रहे हैं;)

159

कृपया this page (अनुभाग "निर्भरता संस्करण रेंज") पर एक नज़र डालें। आप क्या करना चाहते हैं

<version>[1.2.3,)</version> 

ये संस्करण श्रेणियां Maven2 में लागू की गई हैं।

+0

किसी कारण से यह विकल्प मेरे लिए काम नहीं करता है, इसने सीमा के अंदर एक संस्करण चुना लेकिन नवीनतम नहीं। – sorin

+3

आप मैवेन को संस्करण संख्याओं की तुलना करने के तरीके पर नजदीकी नजर डालना चाहेंगे - यदि आप एक सख्त पैटर्न मेवेन के अनुरूप नहीं हैं तो तारों की तुलना में तुलना करें और संख्याएं नहीं। –

+0

वह पृष्ठ कोडहॉस पर है, और खुद को उन चीज़ों के रूप में वर्णित करता है जो "अभी तक मेवेन 2.0 के लिए लागू नहीं किए गए हैं" ... मेवेन प्रलेखन स्वयं संस्करण श्रेणियों के बारे में कुछ भी नहीं कहता है। क्या मैं कुछ भूल रहा हूँ? संस्करण श्रृंखला कब पेश की गई थी? आधिकारिक दस्तावेज में वे कहां वर्णित हैं? – Shannon

290

अब मुझे पता है इस विषय पुराना है, लेकिन सवाल पढ़ने और ओ पी आपूर्ति की जवाब यह Maven Versions Plugin वास्तव में अपने प्रश्न के लिए एक बेहतर जवाब हो सकता है लगता है:

विशेष निम्नलिखित लक्ष्यों काम का हो सकता है में:

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

निम्नलिखित अन्य लक्ष्यों को भी प्रदान की जाती हैं:

  • संस्करणों: प्रदर्शन-निर्भरता-अपडेट एक परियोजना की निर्भरता को स्कैन करता है और उन निर्भरता जो नए संस्करण उपलब्ध है की एक रिपोर्ट पैदा करता है।
  • संस्करण: डिस्प्ले-प्लगइन-अपडेट एक प्रोजेक्ट के प्लगइन स्कैन करता है और उन प्लगइन की एक रिपोर्ट तैयार करता है जिसमें नए संस्करण उपलब्ध हैं।
  • संस्करण: अद्यतन-अभिभावक प्रोजेक्ट के पैरेंट सेक्शन को अद्यतन करता है जो कि यह नवीनतम उपलब्ध संस्करण का संदर्भ देता है। उदाहरण के लिए, यदि आप कॉरपोरेट रूट पीओएम का उपयोग करते हैं, तो लक्ष्य उपयोगी हो सकता है यदि आपको की आवश्यकता है तो सुनिश्चित करें कि आप कॉरपोरेट रूट पीओएम के नवीनतम संस्करण का उपयोग कर रहे हैं।
  • संस्करणों: तो संस्करण वर्तमान प्रोजेक्ट के संस्करण से मेल खाए अद्यतन-बच्चों के मॉड्यूल एक परियोजना के बच्चे मॉड्यूल के माता-पिता अनुभाग अद्यतन करता है। उदाहरण के लिए, यदि आप एक एग्रीगेटर पोम है भी परियोजनाओं है कि यह समुच्चय और बच्चों और माता पिता के संस्करणों तालमेल न बिठा पाएं के लिए माता पिता है कि, इस मोजो मदद कर सकते हैं बच्चे मॉड्यूल के संस्करणों को ठीक। (ध्यान दें कि में इस विकल्प को चलाने के लिए क्रम में इस विकल्प को चलाने के लिए MN को आमंत्रित करें, यदि प्रोजेक्ट इतनी बुरी तरह टूट गया है कि संस्करण गलत मिलान के कारण नहीं बना सकता है)।
  • संस्करणों: लॉक-स्नैपशॉट सभी -SNAPSHOT संस्करणों के लिए पोम खोज करता है और उन्हें उस -SNAPSHOT करें, उदा वर्तमान टाइमस्टैम्प संस्करण के साथ बदलता है -20090327.172306-4
  • संस्करणों: अनलॉक-स्नैपशॉट सभी टाइमस्टैम्प बंद कर दिया स्नैपशॉट संस्करणों के लिए पोम खोज करता है और उन्हें -SNAPSHOT साथ बदल देता है।
  • संस्करण: संकल्प-श्रेणी संस्करण श्रेणियों का उपयोग करके निर्भरता पाता है और विशिष्ट संस्करण का उपयोग करने के लिए सीमा को हल करता है।
  • संस्करणों: उपयोग विज्ञप्ति सभी -SNAPSHOT संस्करणों जो जारी किया गया है के लिए पोम खोज करता है और उसे संगत रिहाई संस्करण के साथ बदल देता है।
  • संस्करणों: उपयोग-अगली रिलीज सभी गैर स्नैपशॉट संस्करणों जो एक नए रिलीज किया गया और उन्हें अगली फिल्म संस्करण के साथ की जगह है पोम खोज करता है।
  • संस्करणों: उपयोग-अगली संस्करणों सभी संस्करणों जो एक नए संस्करण की गई है और उन्हें अगले संस्करण के साथ की जगह के लिए पोम खोज करता है।
  • संस्करण: को pom.xml.versions बैकअप फ़ाइलों को हटा दें। प्रपत्र अंतर्निहित "गरीब आदमी का एससीएम" का एक आधा "।
  • संस्करण: pom.xml.versions बैकअप फ़ाइलों से pom.xml फ़ाइलों को पुनर्स्थापित करता है। प्रपत्र अंतर्निहित "गरीब आदमी का एससीएम" का एक आधा "।

बस सोचा कि मैं इसे भविष्य के संदर्भ के लिए शामिल करूँगा।

+7

इस संदर्भ में, "रिलीज" और "संस्करण" के बीच क्या अंतर है। –

+1

@ बेननोलैंड, मेरा मानना ​​है कि इस मामले में अंतर यह है कि अगले संस्करण को रिलीज आर्टिफैक्ट की आवश्यकता नहीं हो सकती है। जैसे एक आर्टिफैक्ट संस्करण 1.0.0-SNAPSHOT, 1.0.0, और 1.0.1-SNAPSHOT, और 1.0.0-SNAPSHOT के लिए एक पोम संदर्भ दिया गया है, संस्करण: अगले संस्करण और संस्करण: अगली-रिलीज़ 1.0.0 को हल करेंगे, जबकि संस्करण: नवीनतम संस्करण और संस्करण: नवीनतम रिलीज 1.0.1-SNAPSHOT और 1.0.0 सम्मान से हल हो जाएंगे। –

+1

आप यहां इस बहुत अच्छी तालिका में संस्करण/रिलीज/स्नैपशॉट्स के बीच कुछ अनिश्चितताओं को हल कर सकते हैं: http://goo.gl/iDq6PK – Ev0oD

70

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

mvn clean versions:use-latest-versions scm:checkin deploy -Dmessage="update versions" -DperformRelease=true 

है कि मैं निर्भरता अपडेट करें और फिर स्रोत नियंत्रण करने के लिए यह जांच करने के लिए संस्करणों प्लगइन और SCM प्लगइन का उपयोग:

मुझे क्या हडसन/जेनकींस हर निर्माण के लिए निम्न कार्य करते हैं। हां मैंने अपने सीआई को एससीएम चेकइन करने दिया (जिसे आपको मेवेन रिलीज प्लगइन के लिए वैसे भी करना है)।

सेट करने के लिए चाहता हूँ संस्करण केवल आप क्या चाहते हैं अद्यतन करने के लिए प्लगइन:

 <plugin> 
      <groupId>org.codehaus.mojo</groupId> 
      <artifactId>versions-maven-plugin</artifactId> 
      <version>1.2</version> 
      <configuration> 
       <includesList>com.snaphop</includesList> 
       <generateBackupPoms>false</generateBackupPoms> 
       <allowSnapshots>true</allowSnapshots> 
      </configuration> 
     </plugin> 

मैं रिहाई जो -SNAPSHOT का ख्याल रखता है और पुष्टि करता है एक रिलीज़ संस्करण है कि वहाँ ऐसा करने के लिए प्लगइन रिहाई का उपयोग स्नैपशॉट (जो महत्वपूर्ण है)।

यदि आप ऐसा करते हैं तो आप सभी स्नैपशॉट बिल्ड और रिलीज बिल्ड के लिए नवीनतम रिलीज़ संस्करण के लिए नवीनतम संस्करण प्राप्त करेंगे। आपके निर्माण भी पुनरुत्पादित होंगे।

अद्यतन

मैं इस वर्कफ़्लो के बारे में कुछ विशेष पूछ कुछ टिप्पणियाँ देखा। मैं कहूंगा कि हम अब इस विधि का उपयोग नहीं करते हैं और बड़े कारणों से मेवेन संस्करण प्लगइन खराब है और सामान्य रूप से दोषपूर्ण रूप से त्रुटिपूर्ण है।

यह त्रुटिपूर्ण है क्योंकि संस्करणों को समायोजित करने के लिए संस्करण प्लगइन चलाने के लिए सभी मौजूदा संस्करणों को सही ढंग से चलाने के लिए पोम के लिए मौजूद होना आवश्यक है। यह संस्करण प्लगइन किसी भी चीज़ के नवीनतम संस्करण में अपडेट नहीं हो सकता है अगर उसे पोम में संदर्भित संस्करण नहीं मिल रहा है। यह वास्तव में कष्टप्रद है क्योंकि हम अक्सर डिस्क स्पेस कारणों के लिए पुराने संस्करणों को साफ़ करते हैं।

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

कार्यप्रवाह करने के लिए के रूप में कुछ टिप्पणियों के बारे में पूछे जाने पर इसकी हमें क्या करना है कि वापस जा रहे हैं:

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

इस बिंदु पर मेरा मानना ​​है कि रिलीज और ऑटो संस्करण को आपके सामान्य निर्माण से एक अलग उपकरण है।

अब आप एक तरह से maven सोच सकते हैं क्योंकि ऊपर सूचीबद्ध समस्याओं की बेकार लेकिन यह वास्तव में एक निर्माण उपकरण है जो एक कथात्मक आसान बढ़ाई वाक्य रचना (उर्फ एक्सएमएल) पार्स करने के लिए नहीं है के साथ काफी मुश्किल होगा।

असल में हम नामस्थानों के माध्यम से कस्टम एक्सएमएल विशेषताओं को जोड़ने के लिए संकेत देते हैं ताकि संकेत बैश/ग्रोवी स्क्रिप्ट्स (उदाहरण के लिए इस संस्करण को अपडेट न करें)।

+4

चलाएगा, तो आपके उत्तर में प्रेरणा (निरंतर तैनाती) शामिल है। –

+10

मुझे लगता है कि यहां महत्वपूर्ण बिंदु यह है कि इस विधि के साथ पुन: उत्पन्न होता है, जबकि, संस्करण श्रेणी या -टेस्टस्ट का उपयोग करते समय, वे नहीं होते हैं! –

5

जब तक इस सवाल को देखा गया था तब तक संस्करणों के साथ कुछ कंक मेवेन में थे, लेकिन इन्हें मेवेन के नए संस्करणों में हल किया गया है। यह लेख बहुत अच्छी तरह से कब्जा कैसे संस्करण काम और सर्वोत्तम प्रथाओं पर्वतमाला बेहतर कैसे Maven संस्करणों को समझता है समझने के लिए: https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855

+0

जबकि यह सैद्धांतिक रूप से प्रश्न का उत्तर दे सकता है, [यह बेहतर होगा] (// meta.stackoverflow.com/q/8259) यहां उत्तर के आवश्यक हिस्सों को शामिल करने के लिए, और संदर्भ के लिए लिंक प्रदान करें। –

3

सच्चाई, यहां तक ​​कि 3.x में यह अभी भी काम करता है आश्चर्यजनक रूप से परियोजनाओं बनाता है और तैनात। लेकिन नवीनतम/रिलीज कीवर्ड एम 2 ई में समस्याएं पैदा करता है और पूरे स्थान पर ग्रहण करता है, परियोजनाएं भी निर्भरता पर निर्भर करती हैं जो नवीनतम/रिलीज के माध्यम से तैनात की गई संस्करण को पहचानने में असफल होती है।

यदि आप संपत्ति को संपत्ति के रूप में परिभाषित करने का प्रयास करते हैं, तो यह समस्या भी पैदा करेगा, और इसे संदर्भित करें।

तो निष्कर्ष versions-maven-plugin का उपयोग कर सकते हैं यदि आप कर सकते हैं।

22

निर्भरता वाक्यविन्यास Dependency Version Requirement Specification दस्तावेज़ीकरण पर स्थित है। यहां यह पूर्णता के लिए है:

निर्भरता 'version तत्व प्रभावी निर्भरता संस्करण की गणना करने के लिए उपयोग की जाने वाली संस्करण आवश्यकताओं को परिभाषित करता है।

  • 1.0: 1.0 पर "सॉफ्ट" आवश्यकता (सिर्फ एक सिफारिश है, अगर यह निर्भरता के लिए अन्य सभी श्रेणियों से मेल खाता है)
  • [1.0]: "हार्ड" की आवश्यकता पर 1.0
  • संस्करण आवश्यकताओं निम्न सिंटैक्स है (,1.0]: एक्स < = 1,0
  • [1.2,1.3]: 1.2 < = एक्स < = 1,3
  • [1.0,2.0): 1.0 < = एक्स +०१२३८७०३९५2.0
  • [1.5,): x> = 1.5
  • (,1.0],[1.2,): एक्स < = 1.0 या एक्स> = 1.2; एकाधिक सेट अल्पविराम से अलग कर रहे हैं
  • (,1.1),(1.1,): इस शामिल नहीं 1,1

आपके मामले में (उदाहरण के लिए यह इस पुस्तकालय के साथ संयोजन में काम करने के लिए नहीं जाना जाता है), तो आप <version>[1.2.3,)</version>

की तरह कुछ कर सकता है
6

जो कभी भी नवीनतम का उपयोग कर रहा है, कृपया सुनिश्चित करें कि आपके पास है- अन्यथा नवीनतम स्नैपशॉट खींचा नहीं जाएगा।

mvn -U dependency:copy -Dartifact=com.foo:my-foo:LATEST 
// pull the latest snapshot for my-foo from all repositories 
1

कभी कभी तुम नहीं संस्करण पर्वतमाला उपयोग करने के लिए, चाहते हैं, क्योंकि ऐसा लगता है कि वे "धीमी" अपने निर्भरता को हल करने हैं, खासकर जब वहाँ जगह में निरंतर वितरण और संस्करणों की टन कर रहे हैं - भारी दौरान मुख्य रूप से विकास।

versions-maven-plugin का उपयोग करने के लिए एक कार्यवाही होगी। उदाहरण के लिए, यदि आप एक संपत्ति की घोषणा कर सकते हैं:

<properties> 
    <myname.version>1.1.1</myname.version> 
</properties> 

और अपने पोम फाइल करने के लिए संस्करणों-Maven-प्लग-इन जोड़ते: निर्भरता अद्यतन करने के लिए

<build> 
    <plugins> 
     <plugin> 
      <groupId>org.codehaus.mojo</groupId> 
      <artifactId>versions-maven-plugin</artifactId> 
      <version>2.3</version> 
      <configuration> 
       <properties> 
        <property> 
         <name>myname.version</name> 
         <dependencies> 
          <dependency> 
           <groupId>group-id</groupId> 
           <artifactId>artifact-id</artifactId> 
           <version>latest</version> 
          </dependency> 
         </dependencies> 
        </property> 
       </properties> 
      </configuration> 
     </plugin> 
    </plugins> 
</build> 

फिर, क्रम में, आप पर अमल करने के लिए है लक्ष्य:

mvn versions:update-properties validate 

अगर वहाँ एक संस्करण 1.1.1 से अधिक नया, यह आपको बता देगा:

[INFO] Updated ${myname.version} from 1.1.1 to 1.3.2