Различные области применения одного и того же артефакта и переходных зависимостей выпуска

У меня есть проект А, которые используют библиотеку L v1.0.0 с тестовым области. Проект А также зависит от проекта B (с компиляцией области), причем B транзитно зависит от библиотеки L v1.0.0 (с компиляцией области).Различные области применения одного и того же артефакта и переходных зависимостей выпуска

Почему конечный объем библиотеки L для проекта А «тест»? Это вызывает меня NotClassDefFoundError во время выполнения. Представляется, что определение зависимостей проекта А на библиотечном L перекрывает те из переходных зависимостей на L.

Что здесь не так? Мой проект A использует только L для модульных тестов, поэтому я определяю зависимость с областью «test». Но, в конце концов, я хочу, L, чтобы быть на моем пути к классам, так как проект А зависит от проекта В для производства и B необходимо (транзитивно) библиотеки Л.

Спасибо за помощь мне

источник

2012-01-19 Mickael Marrache

В качестве альтернативы предложению Питера, просто оставьте L из зависимостей для A. Вы все равно сможете получить к нему доступ, и Maven будет рассматривать его как зависимость от compile.

Это скрывает, что испытания А зависят от L, хотя.

источник

2012-01-19 10:51:52

Я знаю, что есть некоторые трюки, подобные этому (вот что я использовал сейчас), но я не понимаю, почему это автоматически не включается в область «компиляции». Есть ли объяснение, или это недостаток функции? –

Это позволяет вам конкретно указать область действия, которой вы пользуетесь. Может быть, L «предоставляется» в системе времени выполнения, поэтому для тестирования он нужен только ему. ИМО, то, что отсутствует (для вашего случая), является функцией для определения области независимо для тестирования и производства. –

Но Maven знает, что на путях к проекту B (в дереве зависимостей) зависимости от L имеют область компиляции. Почему он не может решить, что L необходимо для компиляции здесь? Это похоже на ошибку ... Мой проект A использует L для модульных тестов, но есть транзитивные зависимости от L с областью компиляции, я могу сделать вывод, что конечная область должна быть скомпилирована, потому что мне это понадобится на моем пути. –

вы используете Maven? В этом случае, если я правильно помню, Maven будет использовать «ближайшее» определение для определения фактического объема. В этом случае модуль A задает тест, а транзитивная область из B переопределяется, поскольку A близок, поскольку вы на самом деле находитесь в A :) Это становится более сложным, когда у вас есть несколько модулей с зависимостями между ними. Общим средством является определение всех зависимостей (и областей и версий) в общем родительском Pom.xml в теге <dependencyManagement>.

источник

2012-01-19 10:41:55

Тег ''. Вы написали его, но он не отображается в некоторых браузерах. Мне больше нечего добавить к вашему ответу, поэтому я не могу его редактировать. (6 символов изменен минимум.) –

Thx, писал от моего iPhone и его не так хорошо :) –

Даже если я объявляю зависимость к L (с областью компиляции) в общем родительском ПОМ, если зависимость от L объявлена в POM из A имеет «тестовый» охват, конечная область остается «областью». Я вижу, что вы можете заставить использовать специальную версию, но не использовать специальную область, используя этот способ. Единственное решение, которое я вижу сейчас, - это UrsReupke. –

Различные области применения одного и того же артефакта и переходных зависимостей выпуска

ответ

Смежные вопросы