Ответ 1

С 20 февраля 2013 года в Maven Central существует 2.11.0 JAR (и исходных JAR!) Xerces! Смотрите Ксерсес в Maven Central. Интересно, почему они не решили 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 - даже правильный xml-apis-1.4.01 !

И что самое важное (и что не было очевидно в прошлом) - JAR в Maven Central - это тот же JAR, что и в официальном дистрибутиве Xerces-J-bin.2.11.0.zip.

Однако я не смог найти версию xml-schema-1.1-beta - это не может быть версия classifier Maven -ed из-за дополнительных зависимостей.

Ответ 2

Честно говоря, почти все, с чем мы столкнулись, прекрасно работает с версией JAXP, поэтому мы всегда исключаем xml-apis и xercesImpl.

Ответ 3

Вы можете использовать плагин maven enforcer с запрещенным правилом зависимости. Это позволит вам запретить все псевдонимы, которые вы не хотите, и разрешить только тот, который вам нужен. Эти правила будут нарушать работу maven вашего проекта при нарушении. Кроме того, если это правило применяется ко всем проектам на предприятии, вы можете поместить конфигурацию плагина в корпоративную родительскую помню.

см

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

Ответ 4

Я знаю, что это точно не отвечает на вопрос, но для входа ppl из google, которые используют Gradle для управления зависимостями:

Мне удалось избавиться от всех проблем xerces/Java8 с помощью Gradle следующим образом:

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

Ответ 5

Я думаю, есть один вопрос, на который вам нужно ответить:

Есть ли xerces *.jar, что все в вашем приложении может жить?

Если нет, вы в основном ввернуты и должны будете использовать что-то вроде OSGI, которое позволяет одновременно загружать разные версии библиотеки. Будьте предупреждены, что он в основном заменяет проблемы с jar-версией проблемами с загрузкой классов...

Если такая версия существует, вы можете заставить ваш репозиторий вернуть эту версию для всех видов зависимостей. Это уродливое взломать и в итоге приведет к одной и той же реализации xerces в вашем пути к классам несколько раз, но лучше, чем наличие нескольких разных версий xerces.

Вы можете исключить каждую зависимость от ксерок и добавить ее в версию, которую хотите использовать.

Интересно, можете ли вы написать какую-то стратегию разрешения версий в качестве плагина для maven. Это, вероятно, самое приятное решение, но если вообще возможно, потребуются некоторые исследования и кодирование.

Для версии, содержащейся в вашей среде выполнения, вам необходимо убедиться, что она либо удаляется из пути к классу приложений, либо банки приложений считаются первыми для загрузки классов до того, как будет рассмотрена папка lib сервера.

Итак, чтобы обернуть это: это беспорядок, и это не изменится.

Ответ 6

Существует еще один вариант, который не был изучен здесь: объявление зависимостей Xerces в Maven как необязательное:

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

В основном это означает заставить всех иждивенцев объявить свою версию Xerces или их проект не будет компилироваться. Если они хотят переопределить эту зависимость, они могут это сделать, но тогда у них будет потенциальная проблема.

Это создает сильный стимул для последующих проектов:

• Принять активное решение. Они идут с той же версией Xerces или используют что-то еще?
• Собственно проверяйте их разбор (например, через модульное тестирование) и загрузку классов, а также не загромождайте их путь к классам.

Не все разработчики отслеживают недавно введенные зависимости (например, mvn dependency:tree). Этот подход немедленно привлечет внимание к этому вопросу.

Это хорошо работает в нашей организации. До его введения мы жили в том же ад, о котором описывает ОП.

Ответ 7

Сначала вы должны отлаживать, чтобы помочь определить ваш уровень адского 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

в командной строке.

Ответ 8

Что помогло бы, кроме исключения, быть модульными зависимостями.

С одной плоской загрузкой класса (автономное приложение) или полу-иерархическим (JBoss AS/EAP 5.x) это было проблемой.

Но с модульными структурами, такими как OSGi и Модули JBoss, это уже не столько боль. Библиотеки могут использовать любую библиотеку, которую они хотят, независимо.

Конечно, по-прежнему наиболее рекомендуется придерживаться только одной версии и версии, но если нет другого способа (используя дополнительные функции из большего количества библиотек), то модуляция может сэкономить вас.

Хорошим примером модулей 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, не уверен, будет ли она применима для приложений.

Ответ 9

Каждый проект maven должен останавливаться в зависимости от ксерок, но, вероятно, это не так. XML API и Impl были частью Java с 1.4. Не нужно зависеть от xerces или XML API, это похоже на то, что вы зависите от Java или Swing. Это неявно.

Если бы я был боссом maven repo, я бы написал script, чтобы рекурсивно удалить зависимости xerces и написать чтение, в котором говорится, что для этого репо требуется Java 1.4.

Все, что действительно ломается, потому что оно ссылается на Xerces напрямую через импорт org.apache, требуется исправление кода, чтобы довести его до уровня Java 1.4 (и было сделано с 2002 года) или решение на уровне JVM через поддерживаемые библиотеки, а не в maven.

Ответ 10

По-видимому, 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>

Ответ 11

Мой друг, что очень просто, вот пример:

<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>
            </exclusions>
        </dependency>

И если вы хотите проверить в терминале (в этом примере консоль Windows), что у вашего maven-дерева нет проблем:

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