Проблемы, исключающие транзитивную зависимость ссылки на проект от пути к классу eclipse

У меня есть несколько проектов Gradle в моем рабочем пространстве eclipse. Для простоты меня действительно интересуют только 2 из них, давайте просто используем для этого A и B.

Итак, проблема, с которой я сталкиваюсь, заключается в том, что проект A имеет включенную зависимость от JBoss, которая использует javax validation-api 1.0.0.GA, а Project B имеет зависимость от javax validation-api 1.1.0.Final. Поскольку Gradle сам разрешает конфликт, сначала используя более новую библиотеку, B счастлив, когда создается Gradle. Но сам Eclipse содержит ошибки, которые сильно отвлекают при редактировании.

Правильная версия jar-файла validation-api заканчивается в пути к классу B, но проблема в том, что плагин Gradle IDE изменяет зависимость проекта (': A') на ссылку проекта, и Eclipse, кажется, дает ссылке проекта приоритет над внешний кувшин. Так что старая банка предпочтительнее по расширению.

Я попытался добавить { exclude module: 'validation-api' } в build.gradle B для зависимости от A, которая работает в соответствии с выводом «зависимостей gradle», однако, поскольку Eclipse доходит до того, что делает его ссылкой на проект, это не будет исключать банку и проблему останки.

Также на этот вопрос я попытался добавить { transitive = false } и то же самое бывает. Я не думаю, что даже хак, представленный там, сработает для меня, поскольку .classpath содержит единственную ссылку на контейнер Gradle, поэтому удалять нечего.

Мне удалось обойти это, явно включив ссылку на правильную версию jar из моего кеша Gradle, а затем переместив ее над контейнером Gradle Classpath Container, чтобы eclipse сначала увидел эту версию.

Мой вопрос: есть ли лучший/более общий способ сделать это? Предпочтительно тот, который я могу зафиксировать в системе управления версиями, не нарушая сборки других людей и не требуя от них вручную изменять пути или свойства где-либо? Есть еще один проект с похожей проблемой, поэтому кое-что, что я могу исправить в файле build.gradle, было бы здорово.

В худшем случае, я мог бы, вероятно, переключиться на IntelliJ, если он будет вести себя лучше, чем интеграция Eclipse-Gradle?


java gradle eclipse dependency-management gradle-eclipse
person Sloloem    schedule 15.01.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Такого рода проблемы с транзитивной зависимостью являются давней проблемой интеграции Gradle Eclipse (как в инструментах STS, так и в метаданных .classpath, сгенерированных командной строкой из плагина Gradle Eclipse. Проблема заключается в том, как Eclipse вычисляет транзитивные пути к классам.

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

Первое решение — это исправление ошибки, которое изменяет порядок путей к классам зависимостей проекта, чтобы они больше не были «предпочтительнее» над зависимостями jar PR-74. Чтобы получить это исправление, вам может потребоваться установить инструменты gradle с сайта обновления моментальных снимков, поскольку исправление появилось после версии 3.6.3.

Это решение не устраняет реальную проблему (у вас все еще есть «неправильные» вещи в пути к классам), но просто снижает вероятность возникновения реальной проблемы в ваших проектах.

Второе решение состоит в том, чтобы включить использование модели Custom Tooling API PR-55 появился в STS 3.6.3. Это немного экспериментально и работает только для последней версии Gradle, по крайней мере, 1.12, но, вероятно, лучше использовать 2.x. Он также работает только для проектов, в которых включено «Управление зависимостями» (если оно не включено, вы используете .classpath, сгенерированный плагином Gradle eclipse, который имеет те же «сломанные» проблемы с путями к классам, что и инструменты STS).

«Пользовательская модель инструментов» действительно является лучшим решением в принципе, поскольку она исправляет способ сопоставления пути к классам gradle с проектами eclipse, так что зависимости проекта больше не экспортируются, и каждый проект получает свой собственный путь к классам с учетом разрешения конфликтов зависимостей.

Чтобы включить это, перейдите в «Окно >> Настройки >> Gradle» и установите флажок «Использовать пользовательскую модель инструментов».

person Kris    schedule 16.01.2015
comment
Использование Custom Tooling API помогло мне! Обидно, что в многопроектной настройке требуется так много времени на обработку всех моделей... - person Jonathan Naguin; 08.05.2015