2015-01-08 2 views
0

Проект A ссылки Проект B. Проект B включает локальную зависимость. К сожалению, эта локальная зависимость имеет зависимость от net.java.dev.designgridlayout в версии 1.5.Исключение транзитивной зависимости не работает

Мы хотим использовать net.java.dev.designgridlayout в версии 1.11 в проекте A, но мы не можем «перезаписать» зависимость. Eclipse всегда использует зависимость от Project B.

Мы уже пытались исключить версию 1.5 из локальной зависимости, но она не работает. Странно, что Eclipse успешно разрешает класс, добавленный с версией 1.11. Однако для уже существующего класса eclipse решает его из транзитивной зависимости от de.someCompany.

Проект B:

<dependencies> <dependency> <groupId>de.someCompany</groupId> <artifactId>fs-client</artifactId> <version>5.1.209</version> <exclusions> <exclusion> <groupId>net.java.dev.designgridlayout</groupId> <artifactId>designgridlayout</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>net.java.dev.designgridlayout</groupId> <artifactId>designgridlayout</artifactId> <version>1.11</version> </dependency> </dependencies>

Проект А:

<dependencies> <dependency> <groupId>Project-B</groupId> <artifactId>Project-B</artifactId> <version>1503.01</version> </dependency> </dependencies>

Я также попытался включить 1,11 зависимость в проекте А.

Мы даже пытались установить DesignGridLayout V. 1.11 в локальной зависимости и изменить groupID и artifactId на somethi ng different, но по какой-то причине его даже не может найти Eclipse. Если бы можно было включить DesignGridLayout с другим groupId и artifactId, я думаю, что это сработает.

mvn install:install-file -Dfile=lib\designgridlayout.jar -DgroupId=com.company.designgridlayout -DartifactId=design-grid-layout -Dversion=1.11 -DgeneratePom=true -Dpackaging=jar -DlocalRepositoryPath="%USERPROFILE%\.m2\repository"

ответ

0

Не уверен, - но:

Ваш проект А имеет зависимость к себе? Не следует ли использовать проект-b?

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

Если вы добавляете зависимость в свой собственный pom, вам не нужно исключать артефакт, так как groupId и artifactId одинаковы. Версия в вашем собственном пом у победы в проекте-б. Если проект a определяет эту зависимость снова, эта версия будет побеждать.

Я бы сделал mvn dependency:tree на проекте - поместье, чтобы узнать, откуда берутся зависимости.

Для eclipse: он индексирует местный репозиторий. В настройках maven есть кнопка повторного индекса. Поэтому, если вы вручную копируете банки там, которые могут помочь затмению найти артефакт. Но это решение должно быть выполнено на каждой машине. Я бы не стал считать это решением. В мире артефакт-решение является проблемой инфраструктуры и не должно обрабатываться в каждом проекте. То, как это делается, должно быть прозрачным через settings.xml

+0

ops, конечно, я имел в виду Project-B;) –

+0

хорошо :) - зависимость, которую вы ищете в проекте-A, является «designgridlayout»? какая версия maven для этого показала? и откуда оно взялось? – wemu

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