Зависимости спецификации Maven в Gradle - PullRequest
3 голосов
/ 24 января 2020

Учитывая, что в управлении зависимостями проекта Maven есть спецификация Foo , например:

<groupId>someGroup</groupId>
<artifactId>someArtifact-bom</artifactId>
<version>1.0-SNAPSHOT</version>
<type>pom</type>
<scope>import</scope>

, но эта спецификация вступает в действие только для тестовой зависимости в субмодуль.

<dependency>
    <groupId>someGroup</groupId>
    <artifactId>someArtifact</artifactId>
    <scope>test</scope>
</dependency>

Артефакт, объявленный в спецификации и самой спецификации, доступен только путем объявления дополнительного репозитория.

Если я создаю новый проект Maven и объявляю зависимость Foo разрешается.

В случае, если я определяю ту же самую зависимость для Foo в Groovy проекте

repositories {
  mavenCentral()
}

dependencies {
  implementation("myOrg:Foo:1.0")
}

Разрешение не удается с

- Could not resolve myOrg:Foo-parent:1.0.
  - Could not parse POM <mvn-central>/myOrg/Foo-parent-1.0.pom:
    - Could not find someGroup:someArtifact-bom:1.0-SNAPSHOT.

... потому что он не существует в центральном.

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

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

Просто для полноты: после правильного разрешения в моем проекте нет зависимости относительно спецификации или ее артефакта. Это действительно не нужно вообще.

Ответы [ 2 ]

2 голосов
/ 24 января 2020

Чтобы закончить, то, что вы испытали с Gradle, выглядит для меня ожидаемым поведением.

Gradle не будет динамически добавлять репозитории, определенные зависимостями. Это связано с тем, что это может стать угрозой безопасности, когда добавленное хранилище может попытаться скрыть популярные пакеты отравленными артефактами. Поэтому правильным решением в Gradle является добавление дополнительного репозитория при необходимости .

С учетом ряда изменений, внесенных в то, как Gradle интерпретирует спецификации и загружает файлы Maven POM, вполне возможно, что что поскольку спецификация не требуется, более поздняя версия Gradle с радостью проигнорирует ее.

Но проблема root, транзитивно добавляющая случайные репозитории, не будет решена любой версией Gradle.

1 голос
/ 24 января 2020

Благодаря комментарию Corneil du Plessis я более внимательно изучил различные версии Gradle, и более новая версия устранила проблему. Позже, вернувшись к исходной версии, которая поставила меня в известность о проблеме (5.2.1), она продолжала разрешать зависимость без каких-либо ошибок.

Чтобы быть уверенным, что я очистил локальные кэши Gradle и перезапустил сборку с успехом.

Поскольку я больше не могу воспроизвести проблему ни с 5.x, ни с 6.x, я почти уверен, что это было связано с кешем и историей Gradle на моей машине.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...