2010-10-14 20 views
74

यहाँ मेरी सामान्य समस्या है द्वारा जोड़ा ओवरराइड करने के लिए:Maven: कैसे निर्भरता एक पुस्तकालय

मेरे परियोजना पी पर निर्भर करता है एक जो बी जो सी जो डी के

संस्करण 1.0.1 पर निर्भर करता है पर निर्भर करता है पर निर्भर करता है

डी के संस्करण 1.0.1 के साथ एक समस्या है और मैं किसी अन्य मॉड्यूल के उपयोग को मजबूर करना चाहता हूं। मुझे नहीं पता कि यह मेरे प्रोजेक्ट के पीओएम में कैसे घोषित किया जाए क्योंकि मैंने सीधे डी पर निर्भरता नहीं जोड़ा है। यह सी है जिसने डी

पर निर्भरता घोषित की है: इस मामले में, न केवल संस्करण बदल दिया गया है, बल्कि समूह & आर्टिफैक्ट भी है। तो यह केवल निर्भरता के संस्करण को ओवरराइड करने की बात नहीं है, बल्कि मॉड्यूल को छोड़कर और किसी अन्य को शामिल करने का मामला नहीं है।

ठोस मामले में, डी StAX जिसका 1.0.1 एक bug है। बग में नोट के अनुसार, "समस्याओं stax-api-1.0-2 द्वारा stax-api-1.0.1 (Maven ग्रुप = stax) की जगह द्वारा हल कर रहे थे (Maven ग्रुप = javax.xml.stream)" इसलिए मैं मैं बस कोशिश कर रहा हूँ।

इस प्रकार, डी = stax: stax-api: जार: 1.0.1 और सी = org.apache.xmlbeans: xmlbeans: जार: 2.3.0

मैं मामले में Maven 2.0.9 का उपयोग कर रहा है यह मायने रखती है। mvn निर्भरता के

आउटपुट: पेड़ एक ""

mvn dependency:tree 
[..snip..] 
[INFO] +- org.apache.poi:poi-ooxml:jar:3.6:compile 
[INFO] | +- org.apache.poi:poi-ooxml-schemas:jar:3.6:compile 
[INFO] | | +- org.apache.xmlbeans:xmlbeans:jar:2.3.0:compile 
[INFO] | | | \- stax:stax-api:jar:1.0.1:compile 

अपने प्रोजेक्ट के पोम में मैं पर निम्नलिखित निर्भरता ":।

<dependency> 
    <groupId>org.apache.poi</groupId> 
    <artifactId>poi</artifactId> 
    <version>3.6</version> 
</dependency> 
<dependency> 
    <groupId>org.apache.poi</groupId> 
    <artifactId>poi-ooxml</artifactId> 
    <version>3.6</version> 
</dependency> 

अग्रिम धन्यवाद

उत्तर

69

सीधे शब्दों में निर्दिष्ट अपने वर्तमान पोम में संस्करण। संस्करण यहाँ निर्दिष्ट अन्य पर आ जाएगी।

एक संस्करण
एक संस्करण हमेशा अगर यह एक विशेष संस्करण के साथ वर्तमान पोम में घोषित किया जाता है सम्मानित किया जाएगा मजबूर - तथापि, यह ध्यान दिया जाना चाहिए कि यह भी अन्य poms को प्रभावित करेगा नीचे की ओर है, तो यह अपने आप में है सकर्मक का उपयोग कर पर निर्भर निर्भरता।


संसाधन:

+3

यह स्पष्ट नहीं है कि मैं संस्करण को कैसे निर्दिष्ट कर सकता हूं क्योंकि मैं डी पर निर्भरता घोषित नहीं करता हूं। साथ ही, आपके द्वारा प्रदान किया गया पहला लिंक "यह दस्तावेज़ निर्भरता प्रबंधन के लिए शेष आवश्यकताओं का वर्णन करता है जो अभी तक लागू नहीं किए गए हैं मेवेन 2.0, विशेष रूप से संक्रमणीय निर्भरताओं के संबंध में। " शीर्ष पर। – wishihadabettername

+0

@ विशिहाडाबेटर्ननाम, जैसा कि अन्य दस्तावेज़ में कहा गया है: "आप डी 2.0 के उपयोग को मजबूर करने के लिए डी 2.0 में निर्भरता को स्पष्ट रूप से जोड़ सकते हैं" –

+1

आप वास्तव में अपने स्वयं के पोम में प्रविष्टि को डुप्लिकेट करते हैं। अपनी निर्भरता में, निर्दिष्ट करें जो आप चाहते हैं। यह "गहरी" निर्भरताओं द्वारा उपयोग किए जाने वाले किसी भी संस्करण को ओवरराइड करेगा। –

16

वैकल्पिक रूप से, आप बस निर्भरता है कि आप नहीं चाहते बाहर कर सकते हैं। एसटीएक्स जेडीके 1.6 में शामिल है, इसलिए यदि आप 1.6 का उपयोग कर रहे हैं तो आप इसे पूरी तरह से बाहर कर सकते हैं।

मेरे नीचे दिए गए उदाहरण आप के लिए थोड़ा गलत है - आप केवल दो बहिष्करण में से एक की जरूरत है, लेकिन मैं काफी यकीन है कि जो एक नहीं हूँ। मेरे उदाहरण में, के बारे में चल नीचे मैं एक जो बी जो आयातित सी & डी जो प्रत्येक (अभी तक अधिक सकर्मक निर्भरता के माध्यम से) Stax के विभिन्न संस्करणों आयातित आयातित आयात करने गया था Stax के अन्य संस्करणों रहे हैं। तो 'ए' पर निर्भरता में, मैंने स्टैक्स के दोनों संस्करणों को बाहर रखा।

<dependency> 
    <groupId>a.group</groupId> 
    <artifactId>a.artifact</artifactId> 
    <version>a.version</version> 
    <exclusions> 
    <!-- STAX comes with Java 1.6 --> 
    <exclusion> 
     <artifactId>stax-api</artifactId> 
     <groupId>javax.xml.stream</groupId> 
    </exclusion> 
    <exclusion> 
     <artifactId>stax-api</artifactId> 
     <groupId>stax</groupId> 
    </exclusion> 
    </exclusions> 
<dependency> 
+0

यह ध्यान रखना आवश्यक है कि इस संक्रमणीय निर्भरता का उपयोग और बहिष्करण किया जा सकता है यदि आवश्यकता हो तो बिल्ड विफलता का कारण बन सकता है। –

+0

यदि आप एक आधुनिक जेडीके (यानी 1.6+) का उपयोग कर रहे हैं और आपको एक ट्रांजिटिव निर्भरता के माध्यम से शामिल स्टैक्स के पुराने संस्करण की आवश्यकता है, तो आप शायद सभी प्रकार के भयानक रनटाइम क्लास लोडर मुद्दों में भागने जा रहे हैं। मेरी सलाह: जेडीके में से एक का उपयोग करें। यदि आपको "बिल्ड विफलता" मिलती है तो आप किसी प्रपत्र के एक प्राचीन एपीआई पर भरोसा कर रहे हैं जिसे अपग्रेड किया जाना चाहिए। या: अपने जेडीके को 1.5 तक वापस रोल करें। उसके साथ अच्छा भाग्य। – scot

3

मुझे तीसरी पार्टी लाइब्रेरी में निर्भरता को ओवरराल करने में भी परेशानी थी। मैंने बहिष्कार के साथ स्कॉट के दृष्टिकोण का उपयोग किया लेकिन मैंने पोम में नए संस्करण के साथ निर्भरता भी जोड़ा। (मैं Maven 3.3.3 प्रयुक्त)

तो StAX उदाहरण के लिए इसे इस तरह दिखेगा:

<dependency> 
    <groupId>a.group</groupId> 
    <artifactId>a.artifact</artifactId> 
    <version>a.version</version> 
    <exclusions> 
    <!-- STAX comes with Java 1.6 --> 
    <exclusion> 
     <artifactId>stax-api</artifactId> 
     <groupId>javax.xml.stream</groupId> 
    </exclusion> 
    <exclusion> 
     <artifactId>stax-api</artifactId> 
     <groupId>stax</groupId> 
    </exclusion> 
    </exclusions> 
<dependency> 

<dependency> 
    <groupId>javax.xml.stream</groupId> 
    <artifactId>stax-api</artifactId> 
    <version>1.0-2</version> 
</dependency> 
0

क्या आप रूट पोम की </dependencies> टैग के अंदर डाल के सभी बच्चे मॉड्यूल से शामिल किया जाएगा रूट पोम यदि आपके सभी मॉड्यूल उस निर्भरता का उपयोग करते हैं, तो यह तरीका है।

हालांकि, अगर आपके बच्चे के मॉड्यूल में से केवल 10 में से केवल 3 निर्भरता का उपयोग करते हैं, तो आप नहीं चाहते कि यह निर्भरता आपके सभी बाल मॉड्यूल में शामिल हो। उस स्थिति में, आप केवल </dependencyManagement> के अंदर निर्भरता डाल सकते हैं। यह सुनिश्चित करेगा कि निर्भरता की आवश्यकता वाले किसी भी बच्चे मॉड्यूल को इसे अपनी स्वयं की पोम फ़ाइल में घोषित कर देना चाहिए, लेकिन वे उस निर्भरता के उसी संस्करण का उपयोग करेंगे जैसा कि आपके </dependencyManagement> टैग में निर्दिष्ट है।

आप ट्रांजिटिव निर्भरताओं में उपयोग किए गए संस्करण को संशोधित करने के लिए </dependencyManagement> का भी उपयोग कर सकते हैं, क्योंकि ऊपरी अधिकांश पोम फ़ाइल में घोषित संस्करण वह है जिसका उपयोग किया जाएगा। यह उपयोगी हो सकता है यदि आपके प्रोजेक्ट ए में एक बाहरी प्रोजेक्ट बी v1.0 शामिल है जिसमें एक और बाहरी प्रोजेक्ट सी v1.0 शामिल है। कभी-कभी ऐसा होता है कि प्रोजेक्ट सी v1.0 में सुरक्षा उल्लंघन पाया जाता है जिसे v1.1 में ठीक किया जाता है, लेकिन बी के डेवलपर्स सी के v1.1 का उपयोग करने के लिए अपनी प्रोजेक्ट को अपडेट करने में धीमे होते हैं। उस स्थिति में, आप बस घोषित कर सकते हैं आपकी परियोजना के रूट पोम में सी v1.1 पर निर्भरता ', और सबकुछ अच्छा होगा (यह मानते हुए कि बी v1.0 अभी भी सी v1.1 के साथ संकलित करने में सक्षम होगा)।

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