Зависимость знатока в зависимости с другим объемом
MVC позволяет Вам иметь больше чем одну форму на странице, маленькая функция, которую я знаю, но это удобно!
Также шаблон MVC, который я чувствую, делает код легче поддержать, особенно когда Вы пересматривающий его после нескольких месяцев.
4 ответа
Мне это кажется действительно странным, и если это «особенность», я думаю, что это действительно опасно. В любом случае, это не ошибка Maven, и она находится в документации maven здесь .
Что касается лучших практик по этой проблеме, я ничего не слышал, но самый безопасный способ продолжить - полностью удалите xstream из вашего pom, полагаясь на транзитивную зависимость. Это приведет к сбою сборки, если зависимость от mylibrary будет удалена. Это будет действовать как уведомление о том, что вам нужно что-то исправить. Вы не потеряете требуемые зависимости, и у вас не будет незавершенных зависимостей, которые вам больше не нужны.
Кстати, mvn dependency: analysis можно использовать для проверки зависимостей, которые включены, но не используются.
Как говорится в ответе mattb, объявление зависимости как test области переопределяет транзитивное объявление зависимостей в области компиляции, и в результате зависимость не включается в вашу упакованную войну.
Если вам нужна только зависимость в ваших тестах, потому что она нужна mylibrary для выполнения, вам не следует вообще объявлять зависимость в файле pom вашего проекта. Позвольте процессу разрешения транзитивных зависимостей справиться с этим.
Если ваш проект действительно использует jar-файл xstream напрямую, вы все равно можете полагаться на транзитивную зависимость, поскольку вам понадобится совместимая версия для вашего проекта и mylibrary, чтобы они работали с xstream jar. У вас должны быть модульные тесты, которые проверяют эту функциональность, и если mylibrary изменяет версию xstream на несовместимую версию, ваши сборки должны завершиться ошибкой, и вы можете решить проблему на этом этапе.
В общем, я бы сказал, что вам следует избегать объявления версий зависимостей непосредственно в многомодульных проектах. Я объявляю версии в разделе dependencyManagement родительского POM, поэтому дочернему элементу нужно только объявить groupId / artifactId. В качестве альтернативы, начиная с Maven 2.0.9 и далее, существует дополнительная область зависимости import :
Эта область используется только в зависимости типа pom в разделе. Это указывает на то, что указанный POM должен быть заменен зависимостями в этом разделе POM. Поскольку они заменяются, зависимости с областью импорта фактически не участвуют в ограничении транзитивности зависимости.
Таким образом, используя область импорта, вы можете определить свои общие версии зависимостей в одном POM,
Объявляя свою зависимость от xstream и задавая область действия для тестирования, вы переопределяете зависимости, объявленные mylibrary .
На самом деле это функция Maven - он позволяет вам делать такие вещи, как зависеть от более поздней версии транзитивной зависимости в вашем собственном проекте, и не упаковывать две разные версии одного и того же артефакта. Например, вы можете зависеть от версии 1.2.15 log4j, но поскольку вы также используете libraryX , который зависит от log4j-1.2.14 - вы бы не сделали этого » Я хочу, чтобы оба log4j-1.2.15 и log4j-1.2.14 были упакованы вместе с вашим проектом.
Если вы действительно хотите, чтобы xstream был упакован в ваш проект, вам следует не объявлять область как тест .
Если вы хотите его упаковать, зачем вы объявляете область? Если это требуется во время компиляции и выполнения, не следует ли оставлять область действия пустой? Если вы это сделаете, вам понадобится только
<dependency>
<groupId>mycompany.modules</groupId>
<artifactId>submodule</artifactId>
<version>1.0.1</version>
</dependency>
в вашем помпе. Если нет причины описывать его во время компиляции, но не во время упаковки?