ในที่ทำงานของฉันการกล่าวถึงเพียงคำว่า Xerces นั้นเพียงพอที่จะกระตุ้นความโกรธแค้นจากผู้พัฒนา ภาพรวมคร่าวๆของคำถาม Xerces อื่น ๆ เกี่ยวกับ SO ดูเหมือนจะบ่งบอกว่าผู้ใช้ Maven เกือบทั้งหมดนั้น "ถูก" โดยปัญหานี้ในบางจุด น่าเสียดายที่การเข้าใจปัญหาต้องใช้ความรู้เล็กน้อยเกี่ยวกับประวัติของ Xerces ...

ประวัติศาสตร์

• Xerces เป็นตัวแยกวิเคราะห์ XML ที่ใช้กันอย่างแพร่หลายในระบบนิเวศ Java เกือบทุกไลบรารีหรือกรอบงานที่เขียนใน Java ใช้ Xerces ในบางความจุ

• ขวด Xerces รวมอยู่ในไบนารีอย่างเป็นทางการจนถึงทุกวันนี้ ยกตัวอย่างเช่น Xerces 2.11.0 การดำเนินขวดเป็นชื่อและไม่xercesImpl.jarxercesImpl-2.11.0.jar

• ทีม Xerces ไม่ได้ใช้ Mavenซึ่งหมายความว่าพวกเขาไม่ได้อัปโหลดปล่อยอย่างเป็นทางการเพื่อMaven กลาง

• Xerces เคยถูกปล่อยออกมาเป็น jar เดียว ( xerces.jar) แต่ถูกแบ่งออกเป็นสองขวดหนึ่งอันประกอบด้วย API ( xml-apis.jar) และอีกอันหนึ่งมีการใช้งานของ API เหล่านั้น ( xercesImpl.jar) รุ่นเก่าหลาย Maven xerces.jarปอมยังคงประกาศการพึ่งพา เมื่อถึงจุดหนึ่งในอดีต Xerces ก็ได้รับการปล่อยตัวxmlParserAPIs.jarด้วยซึ่ง POM ที่มีอายุมากกว่าก็ขึ้นอยู่กับ

• เวอร์ชันที่กำหนดให้กับขวด xml-apis และ xercesImpl โดยผู้ที่ปรับใช้ไหกับที่เก็บ Maven มักจะแตกต่างกัน ตัวอย่างเช่น xml-apis อาจได้รับรุ่น 1.3.03 และ xercesImpl อาจได้รับรุ่น 2.8.0 แม้ว่าทั้งสองจะมาจาก Xerces 2.8.0 นี่เป็นเพราะคนมักจะติดแท็กขวด xml-apis กับรุ่นของข้อกำหนดที่ใช้ มีความสุขมาก แต่ไม่สมบูรณ์รายละเอียดของที่นี่คือที่นี่

• เพื่อทำให้เกิดความซับซ้อน Xerces คือตัวแยกวิเคราะห์ XML ที่ใช้ในการดำเนินการอ้างอิงของ Java API สำหรับการประมวลผล XML (JAXP) ซึ่งรวมอยู่ใน JRE คลาสการนำไปใช้งานถูกทำแพ็กเกจใหม่ภายใต้com.sun.*เนมสเปซซึ่งทำให้เป็นอันตรายต่อการเข้าถึงโดยตรงเนื่องจากอาจไม่มีอยู่ใน JREs บางตัว อย่างไรก็ตามฟังก์ชั่น Xerces บางส่วนนั้นไม่ได้เปิดเผยผ่านทางjava.*และjavax.*API ตัวอย่างเช่นไม่มี API ที่เปิดเผย Xerces ต่อเนื่อง

• การเพิ่มความสับสนทำให้คอนเทนเนอร์ servlet เกือบทั้งหมด (JBoss, Jetty, Glassfish, Tomcat ฯลฯ ) มาพร้อมกับ Xerces ใน/libโฟลเดอร์ของพวกเขาตั้งแต่หนึ่งตัวขึ้นไป

ปัญหาที่เกิดขึ้น

แก้ปัญหาความขัดแย้ง

สำหรับเหตุผลบางส่วนหรือทั้งหมดข้างต้นองค์กรจำนวนมากเผยแพร่และใช้งานการสร้างแบบกำหนดเองของ Xerces ใน POM ของพวกเขา นี่ไม่ใช่ปัญหาถ้าคุณมีแอปพลิเคชั่นขนาดเล็กและใช้ Maven Central เพียงอย่างเดียว แต่มันกลายเป็นปัญหาอย่างรวดเร็วสำหรับซอฟต์แวร์ระดับองค์กรที่ Artifactory หรือ Nexus กำลังพร็อกซีหลายแหล่งเก็บข้อมูล (JBoss, Hibernate ฯลฯ ):

ตัวอย่างเช่นองค์กร A อาจเผยแพร่xml-apisเป็น:

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

ในขณะเดียวกันองค์กร B อาจเผยแพร่เช่นเดียวjarกับ:

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

แม้ว่าบีjarเป็นรุ่นที่ต่ำกว่าของ A jar, Maven ไม่ทราบว่าพวกเขาเป็นสิ่งประดิษฐ์ที่เหมือนกันเพราะพวกเขามีความแตกต่างกัน groupIdของ ดังนั้นจึงไม่สามารถดำเนินการแก้ไขข้อขัดแย้งและทั้งสอง jarจะถูกรวมเป็นการอ้างอิงที่ได้รับการแก้ไข:

Classloader Hell

ดังกล่าวข้างต้น JRE มาพร้อมกับ Xerces ใน JAXP RI ในขณะที่มันเป็นการดีที่จะทำเครื่องหมาย Xerces Maven dependencies ทั้งหมดว่าเป็น<exclusion>s หรือ as<provided>รหัสบุคคลที่สามที่คุณใช้อาจขึ้นอยู่กับรุ่นที่ให้ไว้ใน JAXP ของ JDK ที่คุณใช้ นอกจากนี้คุณยังต้องจัดส่งขวด Xerces ในคอนเทนเนอร์ servlet ของคุณด้วย สิ่งนี้ทำให้คุณมีตัวเลือกมากมาย: คุณลบเวอร์ชันเซิร์ฟเล็ตและหวังว่าคอนเทนเนอร์ของคุณจะทำงานบนรุ่น JAXP หรือไม่ เป็นการดีกว่าที่จะออกจากเวอร์ชันเซิร์ฟเล็ตและหวังว่าเฟรมเวิร์กแอ็พพลิเคชันของคุณจะรันบนเวอร์ชันเซิร์ฟเล็ตหรือไม่? หากหนึ่งหรือสองของความขัดแย้งที่ยังไม่ได้แก้ไขที่ระบุไว้ข้างต้นจัดการเพื่อจัดส่งผลิตภัณฑ์ของคุณ (ง่ายต่อการเกิดขึ้นในองค์กรขนาดใหญ่) คุณจะพบว่าตัวเองอยู่ใน classloader นรกอย่างรวดเร็วสงสัยว่า Xerces รุ่นใด จะเลือก jar เดียวกันใน Windows และ Linux (อาจจะไม่ใช่)

การแก้ปัญหา?

เราได้พยายามทำเครื่องหมายทั้งหมดอ้างอิง Xerces Maven เป็น<provided>หรือเป็น<exclusion>แต่นี้เป็นเรื่องยากที่จะบังคับใช้ (โดยเฉพาะอย่างยิ่งกับทีมขนาดใหญ่) ที่กำหนดว่าสิ่งประดิษฐ์ที่มีชื่อแทนจำนวนมาก ( xml-apis, xerces, xercesImpl, xmlParserAPIsฯลฯ ) นอกจากนี้ libs / framework ของบุคคลที่สามของเราอาจไม่ทำงานในรุ่น JAXP หรือรุ่นที่จัดทำโดยคอนเทนเนอร์ servlet

เราจะจัดการกับปัญหานี้ได้ดีที่สุดกับ Maven อย่างไร เราจำเป็นต้องใช้การควบคุมที่ละเอียดกว่านี้ขึ้นอยู่กับการพึ่งพาของเราหรือไม่จากนั้นพึ่งพาการทำ classloading แบบทำเป็นชั้น? มีวิธีใดบ้างในการที่จะยกเว้นการพึ่งพา Xerces ทั้งหมดและบังคับให้เฟรมเวิร์ก / libs ทั้งหมดของเราใช้เวอร์ชัน JAXP หรือไม่

อัปเดต : Joshua Spiewak ได้อัปโหลดสคริปต์การสร้าง Xerces build ไปยังXERCESJ-1454 รุ่นที่ได้รับการแก้ไขแล้วซึ่งอนุญาตให้อัพโหลดไปยัง Maven Central ได้ โหวต / เฝ้าดู / มีส่วนร่วมกับปัญหานี้และมาแก้ไขปัญหานี้ทันทีและสำหรับทั้งหมด

มี 2.11.0 JARs (และแหล่ง JARs!)ของ Xerces ใน Maven Central ตั้งแต่วันที่ 20 กุมภาพันธ์ 2013! ดูXerces ใน Maven กลาง ฉันสงสัยว่าทำไมพวกเขาถึงไม่แก้ไข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!

และสิ่งที่สำคัญที่สุด (และสิ่งที่เป็นความไม่ชัดเจนในอดีต) - JAR ใน Maven กลางเป็นขวดเช่นเดียวกับในอย่างเป็นทางการXerces-J-bin.2.11.0.zipจัดจำหน่าย

ฉันไม่สามารถหาxml-schema-1.1-betaรุ่น - มันไม่สามารถเป็นclassifierรุ่นMaven ได้เนื่องจากมีการอ้างอิงเพิ่มเติม

ตรงไปตรงมาทุกอย่างสวยมากที่เราได้พบการทำงานเพียงแค่ปรับ w / รุ่น JAXP ดังนั้นเราเสมอยกเว้น และxml-apisxercesImpl

คุณสามารถใช้ปลั๊กอิน maven enforcer กับกฎการพึ่งพาที่ถูกแบน สิ่งนี้จะช่วยให้คุณสามารถห้ามนามแฝงทั้งหมดที่คุณไม่ต้องการและอนุญาตเฉพาะชื่อที่คุณต้องการ กฎเหล่านี้จะล้มเหลวในการสร้างโครงการของคุณเมื่อมีการละเมิด นอกจากนี้หากกฎนี้ใช้กับโครงการทั้งหมดในองค์กรคุณสามารถกำหนดค่าปลั๊กอินใน parent parent ขององค์กรได้

ดู:

• http://maven.apache.org/plugins/maven-enforcer-plugin/
• http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html

ฉันรู้ว่าสิ่งนี้ไม่ตอบคำถามอย่างแน่นอน แต่สำหรับ ppl ที่มาจาก google ที่ใช้ Gradle สำหรับการจัดการการพึ่งพา:

ฉันจัดการเพื่อกำจัดปัญหาทั้งหมดของ xerces / Java8 กับ Gradle เช่นนี้:

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

ฉันเดาว่ามีคำถามหนึ่งข้อที่คุณต้องตอบ:

มี xerces * .jar อยู่หรือไม่ที่ทุกสิ่งในแอปพลิเคชันของคุณสามารถอยู่ด้วยได้

ถ้าไม่ใช่คุณจะเมาโดยทั่วไปและจะต้องใช้บางอย่างเช่น OSGI ซึ่งช่วยให้คุณโหลดไลบรารีเวอร์ชันต่าง ๆ ในเวลาเดียวกัน ถูกเตือนว่าโดยทั่วไปแล้วมันจะแทนที่ปัญหารุ่น jar กับปัญหา classloader ...

หากมีรุ่นดังกล่าวอยู่คุณสามารถทำให้ที่เก็บของคุณคืนเวอร์ชันนั้นสำหรับการอ้างอิงทุกประเภท มันเป็นการแฮ็กที่น่าเกลียดและจะจบลงด้วยการใช้ xerces เดียวกันใน classpath ของคุณหลายครั้ง แต่ดีกว่ามี xerces หลายรุ่น

คุณสามารถยกเว้นการพึ่งพา xerces ทุกรายการและเพิ่มหนึ่งรายการในเวอร์ชันที่คุณต้องการใช้

ฉันสงสัยว่าคุณสามารถเขียนกลยุทธ์การแก้ปัญหาเวอร์ชันเป็นปลั๊กอินสำหรับ Maven ได้หรือไม่ นี่อาจเป็นทางออกที่ดีที่สุด แต่ถ้าเป็นไปได้ต้องมีการวิจัยและการเข้ารหัส

สำหรับเวอร์ชันที่มีอยู่ในสภาพแวดล้อมรันไทม์ของคุณคุณจะต้องตรวจสอบให้แน่ใจว่าเวอร์ชันนั้นถูกลบออกจาก application classpath หรือขวดแอปพลิเคชันที่ได้รับการพิจารณาก่อนสำหรับการโหลดคลาสก่อนที่จะพิจารณาโฟลเดอร์ lib ของเซิร์ฟเวอร์

ดังนั้นเพื่อสรุป: มันเป็นระเบียบและจะไม่เปลี่ยนแปลง

มีตัวเลือกอื่นที่ยังไม่ได้สำรวจที่นี่: ประกาศการพึ่งพา Xerces ใน Maven เป็นตัวเลือก :

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

โดยทั่วไปสิ่งนี้จะเป็นที่จะบังคับให้อยู่ในความอุปการะทั้งหมดจะประกาศของพวกเขารุ่นของ Xerces หรือโครงการของพวกเขาจะไม่รวบรวม หากพวกเขาต้องการแทนที่การพึ่งพานี้พวกเขายินดีที่จะทำเช่นนั้น แต่พวกเขาจะเป็นเจ้าของปัญหาที่อาจเกิดขึ้น

สิ่งนี้สร้างแรงจูงใจที่แข็งแกร่งสำหรับโครงการปลายน้ำเพื่อ:

• ตัดสินใจอย่างแข็งขัน พวกเขาไปกับ Xerces รุ่นเดียวกันหรือใช้อย่างอื่นหรือไม่
• ทดสอบการแยกวิเคราะห์จริง ๆ (เช่นผ่านการทดสอบหน่วย) และการโหลดคลาสรวมถึงไม่ให้ยุ่งเหยิง classpath ของพวกเขา

นักพัฒนาบางคนไม่ได้ติดตามการอ้างอิงที่เพิ่งเปิดตัวใหม่ (เช่นกับmvn dependency:tree) วิธีการนี้จะนำเรื่องนี้ไปสู่ความสนใจทันที

มันทำงานได้ค่อนข้างดีที่องค์กรของเรา ก่อนการแนะนำเราเคยอยู่ในนรกเดียวกับที่ OP อธิบายไว้

ทุกโครงการ Maven ควรหยุดขึ้นอยู่กับจำนวนศูนย์พวกเขาอาจไม่ได้จริง ๆ XML APIs และ Impl เป็นส่วนหนึ่งของ Java ตั้งแต่ 1.4 ไม่จำเป็นต้องขึ้นอยู่กับ xerces หรือ XML API เช่นมันบอกว่าคุณขึ้นอยู่กับ Java หรือ Swing นี่เป็นนัย

ถ้าฉันเป็นเจ้านายของ repo maven ฉันจะเขียนสคริปต์เพื่อเอาการอ้างอิงซ้ำของ xerces และเขียนอ่านฉันที่บอกว่า repo นี้ต้องใช้ Java 1.4

อะไรก็ตามที่แตกจริงเพราะอ้างอิง Xerces โดยตรงผ่านการอิมพอร์ต org.apache ต้องมีการแก้ไขโค้ดเพื่อนำไปสู่ระดับ Java 1.4 (และทำตั้งแต่ปี 2002) หรือวิธีแก้ปัญหาที่ระดับ JVM ผ่าน libs ที่ได้รับการรับรองไม่ใช่ maven

คุณควรตรวจแก้จุดบกพร่องก่อนเพื่อช่วยระบุระดับนรก 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

ไปยังบรรทัดคำสั่ง

สิ่งที่จะช่วยยกเว้นการยกเว้นนั้นเป็นการพึ่งพาแบบแยกส่วน

ด้วยการโหลดคลาสเดียว (แอปแบบสแตนด์อโลน) หรือกึ่งลำดับชั้น (JBoss AS / EAP 5.x)ปัญหานี้เกิดขึ้น

แต่ด้วยเฟรมเวิร์คโมดูลาร์เช่นOSGiและJBoss Modulesนี่จึงไม่เจ็บปวดอีกต่อไป ห้องสมุดอาจใช้ไลบรารีใดก็ได้ที่ต้องการโดยอิสระ

แน่นอนว่ามันยังคงแนะนำได้ดีที่สุดที่จะยึดติดอยู่กับการใช้งานเพียงครั้งเดียวและรุ่น แต่ถ้าไม่มีวิธีอื่น (ใช้คุณสมบัติพิเศษจาก libs มากขึ้น) การทำให้เป็นโมดูลอาจช่วยให้คุณประหยัดได้

ตัวอย่างที่ดีของโมดูล JBoss ที่ใช้งานจริงคือJBoss AS 7 / EAP 6 / WildFly 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 นั้นง่ายกว่าและเร็วกว่า ในขณะที่คุณสมบัติบางอย่างขาดหายไปก็เพียงพอแล้วสำหรับโครงการส่วนใหญ่ที่เป็น (ส่วนใหญ่) ภายใต้การควบคุมของผู้ขายรายหนึ่งและอนุญาตการบูตอย่างรวดเร็วที่น่าทึ่ง (เนื่องจากการพึ่งพาการแก้ปัญหาการพึ่งพาแบบแยกส่วน)

โปรดทราบว่ามีความพยายามในการทำให้เป็นโมดูลสำหรับ Java 8แต่ AFAIK เป็นหลักในการทำให้เป็นโมดูล JRE เอง แต่ไม่แน่ใจว่าจะใช้กับแอพได้หรือไม่

เห็นได้ชัด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>

เพื่อนของฉันง่ายมากนี่คือตัวอย่าง:

<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>

และถ้าคุณต้องการเช็คอินเทอร์มินัล (ตัวอย่างคอนโซล windows) ว่าต้น maven ของคุณไม่มีปัญหา:

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