मेरे कार्यालय में, Xerces शब्द का मात्र उल्लेख डेवलपर्स से जानलेवा गुस्से को उकसाने के लिए पर्याप्त है। एसओ पर अन्य Xerces प्रश्नों पर एक सरसरी नज़र से संकेत मिलता है कि लगभग सभी मावेन उपयोगकर्ता कुछ बिंदु पर इस समस्या से "छुआ" हैं। दुर्भाग्य से, समस्या को समझने के लिए Xerces के इतिहास के बारे में थोड़ी जानकारी की आवश्यकता है ...

इतिहास

Xerces जावा पारिस्थितिकी तंत्र में सबसे व्यापक रूप से इस्तेमाल किया जाने वाला XML पार्सर है। जावा में लिखा गया लगभग हर पुस्तकालय या ढांचा कुछ क्षमता में Xerces का उपयोग करता है (संक्रमणीय रूप से, यदि सीधे नहीं)।
आधिकारिक बायनेरीज़ में शामिल ज़ेरेस जार आज तक नहीं हैं। उदाहरण के लिए, Xerces 2.11.0 कार्यान्वयन जार का नाम दिया गया है xercesImpl.jarऔर नहीं xercesImpl-2.11.0.jar।
Xerces टीम मावेन का उपयोग नहीं करती है , जिसका अर्थ है कि वे मावेन सेंट्रल को आधिकारिक रिलीज़ अपलोड नहीं करते हैं ।
Xerces को एक जार ( xerces.jar) के रूप में जारी किया जाता था, लेकिन दो जार में विभाजित किया गया था, जिनमें से एक API ( xml-apis.jar) और एक उन API के कार्यान्वयन से युक्त था ( xercesImpl.jar)। कई पुराने मावेन पोम अब भी एक निर्भरता की घोषणा करते हैं xerces.jar। अतीत में कुछ बिंदु पर, Xerces को भी जारी किया गया था xmlParserAPIs.jar, जो कुछ पुराने POMs पर भी निर्भर करता है।
Xml-apis और xercesImpl jars को असाइन किए गए संस्करण, जो अपने जार को Maven रिपॉजिटरी में तैनात करते हैं, वे अक्सर भिन्न होते हैं। उदाहरण के लिए, xml-apis को संस्करण 1.3.03 दिया जा सकता है और xercesImpl को संस्करण 2.8.0 दिया जा सकता है, भले ही दोनों Xerces 2.8.0 से हो। ऐसा इसलिए है क्योंकि लोग अक्सर विनिर्देशों के संस्करण के साथ xml-apis जार को टैग करते हैं जो इसे लागू करता है। यहाँ इस का एक बहुत अच्छा, लेकिन अधूरा टूटना है ।
मामलों को जटिल करने के लिए, Xerces XML पार्सर है जिसे XML प्रसंस्करण के लिए जावा एपीआई (JAXP) के संदर्भ कार्यान्वयन में उपयोग किया जाता है, जो JRE में शामिल है। कार्यान्वयन कक्षाएं com.sun.*नाम-स्थान के तहत निरस्त कर दी जाती हैं , जो उन्हें सीधे एक्सेस करने के लिए खतरनाक बनाता है, क्योंकि वे कुछ राशियों में उपलब्ध नहीं हो सकते हैं। हालाँकि, सभी Xerces की कार्यक्षमता java.*और javax.*API के माध्यम से उजागर नहीं होती है ; उदाहरण के लिए, कोई API नहीं है जो Xerces क्रमांकन को उजागर करता है।
भ्रामक गंदगी को जोड़ते हुए, लगभग सभी सर्वलेट कंटेनर (JBoss, Jetty, Glassfish, Tomcat, आदि), उनके एक या एक से अधिक /libफ़ोल्डरों में Xerces के साथ जहाज ।

समस्या

संघर्ष समाधान

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

एक्सएमएल-एपिस आर्टिफ़ैक्ट द्वारा अनुमानित है

उदाहरण के लिए, संगठन A के xml-apisरूप में प्रकाशित हो सकता है :

<groupId>org.apache.xerces</groupId>
<artifactId>xml-apis</artifactId>
<version>2.9.1</version>

इस बीच, संगठन बी के jarरूप में ही प्रकाशित हो सकता है :

<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>1.3.04</version>

हालाँकि B's jarA की तुलना में कम संस्करण है jar, लेकिन मावेन को यह पता नहीं है कि वे एक ही कलाकृति हैं क्योंकि उनके पास अलग-अलग हैं groupId। इस प्रकार, यह संघर्ष समाधान नहीं कर सकता है और दोनों jarको सुलझे हुए निर्भरता के रूप में शामिल किया जाएगा:

कई xml-apis के साथ निर्भरता को हल किया

क्लास लोडर नर्क

जैसा कि ऊपर उल्लेख किया गया है, JREP RI में XRE के साथ JRE जहाज। जबकि सभी Xerces Maven निर्भरता को <exclusion>s या के रूप में चिह्नित करना अच्छा होगा<provided>आपके द्वारा उपयोग किए जा रहे तृतीय-पक्ष कोड आपके द्वारा उपयोग किए जा रहे JDK के JAXP में दिए गए संस्करण के साथ काम कर सकते हैं या नहीं भी कर सकते हैं। इसके अलावा, आपके पास अपने सर्वलेट कंटेनर में भेजे गए ज़ेरेस जार हैं जिनके साथ संघर्ष करना है। यह आपको कई विकल्पों के साथ छोड़ देता है: क्या आप सर्वलेट संस्करण को हटा देते हैं और आशा करते हैं कि आपका कंटेनर JAXP संस्करण पर चलता है? क्या सर्वलेट संस्करण को छोड़ना बेहतर है, और आशा है कि आपके आवेदन के ढांचे सर्वलेट संस्करण पर चलते हैं? यदि ऊपर उल्लिखित एक या दो अनसुलझे संघर्ष आपके उत्पाद में फिसलने का प्रबंधन करते हैं (एक बड़े संगठन में आसान होना), तो आप जल्दी से खुद को क्लासलोडर नरक में पाते हैं, यह सोचकर कि ज़ेरॉक्स का कौन सा संस्करण रन लोड पर उठा रहा है या नहीं विंडोज और लिनक्स में एक ही जार चुनेंगे (शायद नहीं)।

समाधान?

हम के रूप में सभी Xerces Maven निर्भरता अंकन की कोशिश की है <provided>या एक के रूप में <exclusion>, लेकिन यह देखते हुए लागू करने के लिए (विशेष रूप से एक बड़ी टीम के साथ) के लिए मुश्किल है कि कलाकृतियों इतने सारे उपनाम (है xml-apis, xerces, xercesImpl, xmlParserAPIs, आदि)। इसके अतिरिक्त, JAXP संस्करण या किसी सर्वलेट कंटेनर द्वारा उपलब्ध कराए गए संस्करण पर हमारी तीसरी पार्टी के काम / फ्रेमवर्क नहीं चल सकते हैं।

हम मावेन के साथ इस समस्या का सबसे अच्छा समाधान कैसे कर सकते हैं? क्या हमें अपनी निर्भरता पर इस तरह के बारीक नियंत्रण का प्रयोग करना होगा, और फिर टियरड क्लासलोडिंग पर भरोसा करना होगा? क्या किसी तरह से विश्व स्तर पर सभी Xerces निर्भरता को बाहर करने के लिए, और JAXA संस्करण का उपयोग करने के लिए हमारे सभी चौखटे / लिबास को मजबूर करने का कोई तरीका है?

अद्यतन : यहोशू Spiewak ने XERESJ-1454 में Xerces build स्क्रिप्ट का एक पैच संस्करण अपलोड किया है जो Maven Central में अपलोड करने की अनुमति देता है। इस मुद्दे पर वोट दें / देखें / योगदान करें और इस समस्या को एक बार और सभी के लिए ठीक करें।

— जस्टिन गैरिक
स्रोत

8

इस विस्तृत प्रश्न के लिए धन्यवाद। मुझे xerces टीम की प्रेरणा समझ में नहीं आती है। मुझे लगता है कि वे वहाँ उत्पाद पर गर्व कर रहे हैं और अन्य का उपयोग कर खुशी ले रहे हैं लेकिन xerces और maven अपमानजनक की वर्तमान स्थिति। फिर भी, वे वही कर सकते हैं जो वे चाहते हैं भले ही इससे मुझे कोई मतलब न हो। मुझे आश्चर्य है कि अगर sonatype लोगों के पास कोई सुझाव है।

— ट्रैविस श्नीबर्गर

35

यह शायद विषय है, लेकिन यह शायद मैंने कभी देखा बेहतर पोस्ट है। प्रश्न से अधिक, आप जो वर्णन करते हैं, वह सबसे दर्दनाक समस्या में से एक है जिसका हम सामना कर सकते हैं। बड़ी पहल!

— जीन-रेमी रेव

2

@TravisSchneeberger जटिलता बहुत है क्योंकि सूर्य ने JRE में ही Xerces का उपयोग करना चुना था। आप शायद ही इसके लिए Xerces के लोगों को दोषी ठहरा सकते हैं।

— थोरबजोरन रावन एंडरसन

आमतौर पर हम Xerces के एक संस्करण को खोजने की कोशिश करते हैं जो परीक्षण और त्रुटि के आधार पर सभी आश्रित पुस्तकालयों को संतुष्ट करता है, यदि यह संभव नहीं है तो आवेदन को अलग-अलग WAR (अलग श्रेणी लोडर) में विभाजित करने के लिए WARs को रिफ्लेक्टर करें। यह उपकरण (मैंने इसे लिखा था) यह समझने में मदद करता है कि jhades.org पर क्या चल रहा है , क्लास के लिए जार और वर्गों को क्वेरी करने की अनुमति देकर - यह उस स्थिति में भी काम करता है जब सर्वर अभी तक शुरू नहीं होता है

— कोणीय विश्वविद्यालय

बस एक त्वरित टिप्पणी यदि आप विंडोज़ में git bash से servicemix शुरू करते समय यह त्रुटि प्राप्त कर रहे हैं: इसके बजाय इसे "सामान्य" cmd से प्रारंभ करें।

— अल्बर्ट हेंड्रिक्स

112

2.11.0 जार रहे हैं (और स्रोत जार!) 20 वीं फरवरी 2013 के बाद से Maven मध्य में Xerces की! मावेन सेंट्रल में Xerces देखें । मुझे आश्चर्य है कि उन्होंने https://issues.apache.org/jira/browse/XERCESJ-1454 का समाधान क्यों नहीं किया ...

मैंने उपयोग किया है:

<dependency>
    <groupId>xerces</groupId>
    <artifactId>xercesImpl</artifactId>
    <version>2.11.0</version>
</dependency>

और सभी निर्भरताओं ने ठीक हल किया है - उचित भी xml-apis-1.4.01!

और जो सबसे महत्वपूर्ण है (और जो अतीत में स्पष्ट नहीं था) - मावेन सेंट्रल में जेएआर वही है जो आधिकारिक Xerces-J-bin.2.11.0.zipवितरण में है ।

मुझे हालांकि xml-schema-1.1-betaसंस्करण नहीं मिला - classifierअतिरिक्त निर्भरता के कारण यह मावेन-आधारित संस्करण नहीं हो सकता ।

— ग्रेज़गोरज़ ग्राज़ीबेक
स्रोत

9

हालांकि यह है बहुत भ्रामक है कि xml-apis:xml-apis:1.4.01है नए से xml-apis:xml-apis:2.0.2?? देख search.maven.org/...

— हेंडी इरावन

यह भ्रामक है, लेकिन यह गैर-संस्करण वाले ज़ेर्सेस जार के तीसरे पक्ष के अपलोड के कारण है, जैसे कि जस्टिंगरिक अपने पोस्ट में कह रहा था। xml-apis 2.9.1 1.3.04 के समान है, इसलिए इस अर्थ में, 1.4.01 1.3.04 के लिए नया (और संख्यात्मक रूप से बड़ा) है।

— liltitus27 15

1

यदि आपके पास अपने pom.xml में xercesImpl और xml-एपिस दोनों हैं, तो xml-apis निर्भरता को हटाना सुनिश्चित करें! अन्यथा 2.0.2 उसके बदसूरत सिर को चीरता है।

— मिकराजमासी 56

64

सच कहूँ तो, बहुत ज्यादा सब कुछ है कि हम काम करता है बस ठीक w / JAXP संस्करण है, तो हम हमेशा बाहर xml-apis और xercesImpl।

— jtahlborn
स्रोत

13

क्या आप इसके लिए pom.xml स्निपेट जोड़ सकते हैं?

— चज़ब्रगला

10

जब मैं यह कोशिश करता हूं, तो मुझे रनवे पर JavaMelody और Spring फेंकना पड़ता java.lang.NoClassDefFoundError: org/w3c/dom/ElementTraversalहै।

— डेविड मोल्स

डेविड मोल्स की प्रतिक्रिया में जोड़ने के लिए - मैंने देखा है कि आधा दर्जन सकर्मक निर्भरताओं को एलीमेंटट्रैवल की जरूरत है। वसंत और Hadoop में विभिन्न चीजें सबसे अधिक।

— स्कॉट केरी

2

यदि आपको java.lang.NoClassDefFoundError: org / w3c / dom / ElementTraversal अपने pom में xml-apis 1.4.01 जोड़ने का प्रयास करें (और अन्य सभी आश्रित संस्करणों को बाहर करें)

— जस्टिन रोवे

1

ElementTraversal एक नया वर्ग है जो Xerces 11 में जोड़ा गया है और xml-apis: xml-apis: 1.4.01 निर्भरता में उपलब्ध है। इसलिए आपको क्लास को मैन्युअल रूप से अपनी परियोजना में कॉपी करने या संपूर्ण निर्भरता का उपयोग करने की आवश्यकता हो सकती है जो क्लास लोडर में डुप्लिकेट कक्षाओं का कारण बनता है। लेकिन JDK9 में इस वर्ग को शामिल किया गया था इसलिए आपको डिपो को हटाने की आवश्यकता हो सकती है।

— सेर्गेई पोनोमेर्व

42

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

देख:

— ट्रैविस श्नीबर्गर
स्रोत

33

मुझे पता है कि यह सवाल का सही जवाब नहीं देता है, लेकिन Google से आने वाले पीपीएल के लिए जो ग्रैडल का उपयोग उनके निर्भरता प्रबंधन के लिए होता है:

मैं इस तरह ग्रेड के साथ सभी xerces / Java8 मुद्दों से छुटकारा पाने में कामयाब रहे:

configurations {
    all*.exclude group: 'xml-apis'
    all*.exclude group: 'xerces'
}

— netmikey
स्रोत

36

अच्छा, मावेन के साथ आपको XML की लगभग 4000 पंक्तियों की आवश्यकता होगी।

— टेकनोपुल

यह समस्या हल नहीं हुई। Android- ग्रैडल लोगों के लिए कोई अन्य संकेत?

— nyxee

2

@teknopaul XML का उपयोग शुद्ध रूप से कॉन्फ़िगरेशन के लिए किया जाता है। ग्रूवी एक उच्च स्तरीय प्रोग्रामिंग भाषा है। कभी-कभी आप अपने जादू के लिए ग्रूवी के बजाय एक्साइटिक गवाह के लिए एक्सएमएल का उपयोग करना चाह सकते हैं।

— ड्रैगस

16

मुझे लगता है कि एक सवाल है जिसका आपको जवाब देना चाहिए:

वहाँ एक xerces * .jar मौजूद है कि आपके आवेदन में सब कुछ के साथ रह सकते हैं?

यदि आप मूल रूप से खराब नहीं हुए हैं और आपको OSGI जैसी किसी चीज़ का उपयोग करना होगा, जो आपको एक ही समय में भरी हुई लाइब्रेरी के विभिन्न संस्करणों के लिए अनुमति देता है। चेतावनी दी है कि यह मूल रूप से क्लास वर्कर मुद्दों के साथ जार संस्करण मुद्दों की जगह ...

यदि ऐसा कोई संस्करण मौजूद है, तो आप सभी प्रकार की निर्भरताओं के लिए अपने भंडार को वापस कर सकते हैं। यह एक बदसूरत हैक है और कई बार आपके क्लासपथ में एक ही xerces कार्यान्वयन के साथ समाप्त होगा, लेकिन xerces के कई अलग-अलग संस्करण होने से बेहतर है।

आप xerces के लिए हर निर्भरता को बाहर कर सकते हैं और उस संस्करण को जोड़ सकते हैं जिसे आप उपयोग करना चाहते हैं।

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

आपके रनटाइम वातावरण में निहित संस्करण के लिए, आपको यह सुनिश्चित करना होगा कि यह या तो एप्लिकेशन क्लासपाथ से हटा दिया जाए या एप्लिकेशन जार को क्लास लोडिंग के लिए पहले माना जाए, इससे पहले कि सर्वर के आवश्यक फ़ोल्डर पर विचार किया जाए।

तो इसे लपेटने के लिए: यह एक गड़बड़ है और यह नहीं बदलेगा।

— जेन्स स्काउडर
स्रोत

1

एक ही जार से अलग ClassLaders द्वारा लोड की गई एक कक्षा अभी भी एक ClassCastException (सभी मानक कंटेनरों में) है

— अजाक्स

3

बिल्कुल सही। इसलिए मैंने लिखा है: चेतावनी दी है कि यह मूल रूप से क्लास वर्कर मुद्दों के साथ जार संस्करण के मुद्दों की जगह लेता है

— जेन्स स्काउडर

7

एक और विकल्प है जो यहां नहीं खोजा गया है: मावेन में एक्सरेसेस निर्भरता को वैकल्पिक के रूप में घोषित करना :

<dependency>
   <groupId>xerces</groupId>
   <artifactId>xercesImpl</artifactId>
   <version>...</version>
   <optional>true</optional>
</dependency>

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

यह निम्न परियोजनाओं के लिए एक मजबूत प्रोत्साहन बनाता है:

सक्रिय निर्णय लें। क्या वे Xerces के समान संस्करण के साथ जाते हैं या कुछ और उपयोग करते हैं?
वास्तव में उनके पार्सिंग (जैसे इकाई परीक्षण के माध्यम से) और क्लास लोडिंग का परीक्षण करें और साथ ही उनके क्लासपाथ को अव्यवस्थित न करें।

सभी डेवलपर नई शुरू की गई निर्भरताओं (जैसे के साथ mvn dependency:tree) का ट्रैक नहीं रखते हैं । यह दृष्टिकोण तुरंत मामले को उनके ध्यान में लाएगा।

यह हमारे संगठन में काफी अच्छा काम करता है। इसकी शुरूआत से पहले, हम उसी नरक में रहते थे, जिसका ओपी वर्णन कर रहा है।

— डैनियल
स्रोत

क्या मुझे संस्करण तत्व के भीतर सचमुच डॉट-डॉट का उपयोग करना चाहिए, या क्या मुझे 2.6.2 जैसे वास्तविक संस्करण का उपयोग करने की आवश्यकता है?

— क्रिसिनटाउन

3

@chrisinmtown असली संस्करण।

— डैनियल

6

हर मावेन परियोजना को xerces के आधार पर रोकना चाहिए, वे शायद वास्तव में नहीं हैं। XML API और एक Impl 1.4 के बाद से Java का हिस्सा है। Xerces या XML API पर निर्भर होने की आवश्यकता नहीं है, जैसे कि आप जावा या स्विंग पर निर्भर करते हैं। यह निहित है।

अगर मैं एक मावेन रेपो का मालिक था, तो मैं एक स्क्रिप्ट लिखूंगा कि ज़ीरक्सिस निर्भरता को हटा दें और मुझे एक रीड लिखें जो कहता है कि इस रेपो को जावा 1.4 की आवश्यकता है।

जो कुछ भी वास्तव में टूटता है क्योंकि यह ऑरिजनल के माध्यम से सीधे Xerces को संदर्भित करता है। कैश आयात को जावा 1.4 स्तर तक लाने के लिए कोड फिक्स की आवश्यकता होती है (और 2002 के बाद से किया गया है) या जेवीएम स्तर पर एंडोर्स किए गए कामों के माध्यम से समाधान, मावेन में नहीं।

— teknopaul
स्रोत

आपके द्वारा विस्तृत किए गए रिफ्लेक्टर को निष्पादित करते समय, आपको अपनी जावा फ़ाइलों और कॉन्फ़िगरेशन के पाठ में पैकेज और वर्ग नामों की खोज करने की भी आवश्यकता होती है। आप पाएंगे कि डेवलपर्स ने Impl क्लासेस के FQN को लगातार स्ट्रिंग्स में डाल दिया है जो Class.forName और इसी तरह के कंस्ट्रक्शन द्वारा उपयोग किए जाते हैं।

— डेरेक बेनेट

यह मानता है कि सभी SAX कार्यान्वयन समान कार्य करते हैं, जो कि सत्य नहीं है। xercesImpl लाइब्रेरी कॉन्फ़िगरेशन विकल्पों के लिए अनुमति देता है जो java.xml.parser लाइब्रेरीज़ की कमी है।

— अमलगोविनस

6

XML नरक के अपने स्तर की पहचान करने में मदद करने के लिए, आपको पहले डीबग करना चाहिए। मेरी राय में, पहला कदम जोड़ना है

-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl
-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl

कमांड लाइन के लिए। यदि वह काम करता है, तो पुस्तकालयों को छोड़कर शुरू करें। यदि नहीं, तो जोड़ें

-Djaxp.debug=1

कमांड लाइन के लिए।

— डेरेक बेनेट
स्रोत

2

सिवाय इसके क्या मदद मिलेगी, सिवाय इसके कि मॉड्यूलर निर्भरता है।

एक फ्लैट क्लास लोडिंग (स्टैंडअलोन ऐप), या अर्ध-पदानुक्रमित (JBoss AS / EAP 5.x) के साथ यह एक समस्या थी।

लेकिन OSGi और JBoss मॉड्यूल जैसे मॉड्यूलर फ्रेमवर्क के साथ , यह अब इतना दर्द नहीं है। पुस्तकालय जो भी चाहें पुस्तकालय का उपयोग कर सकते हैं, स्वतंत्र रूप से।

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

कार्रवाई में जेबॉस मॉड्यूल का एक अच्छा उदाहरण है, स्वाभाविक रूप से, जेबॉस एएस 7 / ईएपी 6 / वाइल्डफली 8 , जिसके लिए इसे मुख्य रूप से विकसित किया गया था।

उदाहरण मॉड्यूल परिभाषा:

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.jboss.msc">
    <main-class name="org.jboss.msc.Version"/>
    <properties>
        <property name="my.property" value="foo"/>
    </properties>
    <resources>
        <resource-root path="jboss-msc-1.0.1.GA.jar"/>
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="org.jboss.logging"/>
        <module name="org.jboss.modules"/>
        <!-- Optional deps -->
        <module name="javax.inject.api" optional="true"/>
        <module name="org.jboss.threads" optional="true"/>
    </dependencies>
</module>

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

ध्यान दें कि जावा 8 के लिए एक मॉड्यूलर प्रयास चल रहा है , लेकिन AFAIK जो मुख्य रूप से JRE को संशोधित करना है, यह सुनिश्चित नहीं है कि यह ऐप्स पर लागू होगा या नहीं।

— ओंद्रा ndižka
स्रोत

jboss मॉड्यूल स्थैतिक संशोधन के बारे में है। यह रनटाइम मॉडर्नाइजेशन के साथ बहुत कम है OSGi को पेश करना है - मैं कहूंगा कि वे एक-दूसरे की तारीफ करेंगे। हालांकि यह एक अच्छी प्रणाली है।

— eis

* प्रशंसा के बदले पूरक

— रॉबर्ट माइक

2

जाहिरा तौर पर xerces:xml-apis:1.4.01मावेन केंद्रीय में नहीं है, जो हालांकि xerces:xercesImpl:2.11.0संदर्भ है।

यह मेरे लिए काम करता है:

<dependency>
  <groupId>xerces</groupId>
  <artifactId>xercesImpl</artifactId>
  <version>2.11.0</version>
  <exclusions>
    <exclusion>
      <groupId>xerces</groupId>
      <artifactId>xml-apis</artifactId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>xml-apis</groupId>
  <artifactId>xml-apis</artifactId>
  <version>1.4.01</version>
</dependency>

— thrau
स्रोत

1

मेरा मित्र जो बहुत सरल है, यहाँ एक उदाहरण है:

<dependency>
    <groupId>xalan</groupId>
    <artifactId>xalan</artifactId>
    <version>2.7.2</version>
    <scope>${my-scope}</scope>
    <exclusions>
        <exclusion>
        <groupId>xml-apis</groupId>
        <artifactId>xml-apis</artifactId>
    </exclusion>
</dependency>

और अगर आप टर्मिनल में जांच करना चाहते हैं (इस उदाहरण के लिए विंडोज़ कंसोल) कि आपके मावेन पेड़ को कोई समस्या नहीं है:

mvn dependency:tree -Dverbose | grep --color=always '(.* conflict\|^' | less -r

— एडुआर्डो
स्रोत

जावा / मावेन में "Xerces नर्क" से निपटना?

इतिहास

समस्या

संघर्ष समाधान

क्लास लोडर नर्क

समाधान?