Почему добавление тестовой банки взорвало эту сборку Maven?

Question

Ладно, сейчас меня раздражает немного из-за Maven 2. Настройка проекта, которую мы получили, проста: «основной» проект, который зависит как от «пакетного», так и от «веб» проекта, и «ушной» проект, который зависит от «сети». Довольно простые вещи.

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

Этот текущий (скрытый) XML включен в веб-пометку, чтобы включить основной проект в качестве зависимости:

<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>XYZ-core</artifactId>
<version>${project.version}</version>
</dependency>

Пом работает, если просто это включено, как и остальные файлы JAR включены. Один из jar-файлов - это сервлет api, 2.4 - версия:

<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>${version.servlet-api}</version>
<scope>provided</scope>
</dependency>

Это устанавливается в объеме, указанном веб-контейнером. Там нет сюрпризов. Имея только это в веб-помпе, он запускает тесты и устанавливает без проблем.

Но теперь в сети есть все эти издевательства. Пакет может использовать некоторые из этих издевательств тоже. Поэтому, естественно, я хочу поместить ядро ​​ tests в качестве проверки объема как в пакете, так и в сети, чтобы я мог перенести макеты (которые имитируют функциональность ядра) в тест ядра, чтобы они могли быть общими для проектов. Следующий фрагмент (скрытый) работает в пакетном проекте:

<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>XYZ-core</artifactId>
<classifier>tests</classifier>
<version>${project.version}</version>
<scope>test</scope>
</dependency>

Однако, когда я добавляю это в веб-pom, я получаю все это, когда пытаюсь создать веб.

XYZ.java: [33,16] не может разрешить символьный символ: class HttpServletRequest

Если он удален, веб-сборка успешно выполняется.

Есть идеи? Maven версия 2.0.4. Я могу попытаться обновить, но это будет много хлопот.

РЕДАКТИРОВАТЬ: основные классы веб не в состоянии скомпилировать с этой ошибкой (также HttpServletResponse также не найден). Даже если тесты пропущены (-Dmaven.test.skip = true), эта ошибка возникает.

Answer 1

Maven 2.0.4 уже три года, и он предшествует довольно критическому изменению способа взаимодействия Maven 2 с версиями плагинов. До версии Maven 2.0.9 сборка Maven загружала последнюю версию всех необходимых плагинов. Скорее всего, вы столкнулись с несоответствием, потому что вы используете более новый плагин с Maven 2.0.4. Прежде чем что-либо предпринимать, обновитесь до версии Maven 2.0.9, несмотря на все трудности. Я удивлен, что вы все еще можете собрать с 2.0.4.

В настоящее время вам следует рассмотреть возможность обновления до 2.0.10 или 2.1.0. Основное отличие состоит в том, что 2.1.0 содержит некоторые улучшения параллельной загрузки и поддержку зашифрованных паролей сервера.

Answer 2

Вы должны проверить mvn help: эффективный pom с порцией оскорбления и без нее.

Вы также можете быть укушены этой ошибкой , но вам нужно будет выяснить, относится ли она к вашей ситуации с родителями.

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

Answer 3

Это не проблема с вашим дистрибутивом maven.

Как правило, используйте mvn dependency:tree при попытке выяснить, почему определенные зависимости не включены в их ожидаемые артефакты или область действия.

В вашем случае, хотя у вас есть артефакт сервлет-API, доступный как предоставленная зависимость, вам на самом деле нужна реализация, доступная на этапе тестирования. Мне кажется, что тесты, которые вы запускаете в пакетном режиме, никогда не импортируют ваши фиктивные классы, которые импортируют что-либо из javax.servlet, но ваши тесты в Интернете действительно импортируют макеты, которые импортируют что-то из javax.servlet. .

Я бы рассмотрел добавление некоторых реализаций Jetty в качестве зависимости с областью тестирования и посмотрел, получит ли это дальнейшее развитие.