Разрешение самостоятельной зависимости Gradle

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

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


Я пытаюсь загрузить генератор кода, который использует более раннюю версию для создания части своего кода Java. Сам генератор кода работает, как и плагин Gradle, который я написал для него. Проблема в том, что плагин требует указать зависимость, чтобы объявить, какую версию моего инструмента использовать. Так что у проекта есть зависимость от самого себя (хотя и более старая версия).

build.gradle инструмента выглядит так:

plugins {
    id 'java'
    id 'de.clashsoft.gentreesrc-gradle' version '1.2.3'
    id 'maven-publish'
}

// name = 'gentreesrc' (settings.gradle)
version = '0.3.1'
group   = 'de.clashsoft'

repositories {
    // where the artifact is published
    jcenter()
}

dependencies {
    // the configuration added by the plugin
    gentreesrc group: 'de.clashsoft', name: 'gentreesrc', version: '0.3.1'
}

// publishing configuration...

Теперь плагин создает конфигурацию gentreesrc (без всяких наворотов) и задачу с именем gentreesrcJava:

task gentreesrcJava(type: JavaExec) {
    // ...
    classpath = configurations.gentreesrc
    main = 'de.clashsoft.gentreesrc.Main'
    // ...
}

Когда я пытаюсь запустить эту задачу в своем проекте инструмента, я получаю сообщение об ошибке:

> Task :gentreesrcJava FAILED

Error: Could not find or load main class de.clashsoft.gentreesrc.Main

Я отследил проблему до разрешения моей зависимости gentreesrc: вместо того, чтобы разрешить ее для опубликованного артефакта в jcenter, он использует несуществующий артефакт в build/libs/, как видно из этого вывода:

/Users/me/projectDir/build/libs/gentreesrc-0.3.1.jar
/Users/me/.gradle/caches/modules-2/files-2.1/org.antlr/antlr4-runtime/4.7.2/e27d8ab4f984f9d186f54da984a6ab1cccac755e/antlr4-runtime-4.7.2.jar
/Users/me/.gradle/caches/modules-2/files-2.1/org.antlr/ST4/4.1/467d508be07a542ad0a68ffcaed2d561c5fb2e0c/ST4-4.1.jar
/Users/me/.gradle/caches/modules-2/files-2.1/commons-cli/commons-cli/1.4/c51c00206bb913cd8612b24abd9fa98ae89719b1/commons-cli-1.4.jar
/Users/me/.gradle/caches/modules-2/files-2.1/org.antlr/antlr-runtime/3.5.2/cd9cd41361c155f3af0f653009dcecb08d8b4afd/antlr-runtime-3.5.2.jar

следующего дополнения к build.gradle:

gentreesrcJava.doFirst {
    gentreesrcJava.classpath.each { println it }
}

Интересно, что это также происходит, когда я изменяю часть version = '0.3.1' на version = '0.4.0' (первая строка вывода пути к классам изменяется на /Users/me/projectDir/build/libs/gentreesrc-0.4.0.jar). Однако запись version = '0.2.0' не вызывает проблем (сборка не дает сбоев и работает как положено).


Теперь к самому вопросу: почему Gradle разрешает зависимость именно так (к артефакту в build/libs/)? Есть ли способ игнорировать этот артефакт и принудительно разрешать через jcenter?


person Clashsoft    schedule 27.04.2019    source источник
comment
Вы пробовали использовать классификаторы артефактов? просто опубликуйте свои артефакты с дополнительным классификатором и попробуйте использовать его в качестве зависимости от старой версии... Не уверен, что это сработает, но попробовать стоит.   -  person Sheinbergon    schedule 28.04.2019


Ответы (1)


Gradle по умолчанию сопоставляет бинарные зависимости с идентификаторами проекта и выполняет обычное разрешение конфликтов.

Поэтому, если ваш плагин является более поздней версией того же group:name, вы не сможете разрешить более старую версию из внешнего репозитория. Тот факт, что он работает с 0.2.0, странен. Есть вероятность, что вы также изменили group или name?

Чтобы найти обходные пути, см. систему отслеживания проблем Gradle.

person Louis Jacomet    schedule 28.04.2019
comment
Спасибо, обходной путь по ссылке решил проблему. Возможно, вам следует включить его в свой ответ на случай, если ссылка не работает. Я не менял группу или имя с момента запуска проекта. - person Clashsoft; 28.04.2019