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

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

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

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

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

pom работает, если включено только это, а также остальные включенные файлы jar. Один из включенных jar-файлов — это API-интерфейс сервлета, версия 2.4:

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

Для этого задана область действия, поскольку она будет предоставлена ​​веб-контейнером. Никаких сюрпризов. Только с этим в веб-памяти он запускает тесты и устанавливает без проблем.

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

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

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

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

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

Любые идеи? Версия мавена 2.0.4. Я могу попытаться обновить, но это будет означать много хлопот.

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


build testing maven-2
person MetroidFan2002    schedule 12.02.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Вы должны проверить mvn help: Effective-pom с оскорбительным фрагментом и без него.

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

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

person Zac Thompson    schedule 13.02.2009
comment
Интересный факт об эффективных помпонах. Эта проблема действительно была решена путем обновления до maven 2.0.9, хотя у плагина сайта были проблемы, и мне пришлось вручную установить его обратно на версию 2.0. - person MetroidFan2002; 17.02.2009

arrow_upward
2
arrow_downward

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 содержит некоторые улучшения параллельной загрузки и поддержку зашифрованных серверных паролей.

person Tim O'Brien    schedule 31.03.2009

arrow_upward
0
arrow_downward

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

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

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

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

person whaley    schedule 12.02.2009
comment
Я не верю, что у ядра есть какие-либо зависимости от сервлета, но я могу ошибаться. Если это так, необходимо перенастроить зависимости ядра, поскольку предполагается, что оно является общим как для пакетной обработки, так и для сети, но не касается ни одного из проектов (без подробностей). - person MetroidFan2002; 13.02.2009
comment
О, извините, я также забыл, где возникают ошибки - основные классы, это даже не работает, когда тесты пропускаются. Я добавлю это к вопросу. - person MetroidFan2002; 13.02.2009