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

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

0 голосов
/ 28 апреля 2019

Прежде всего, извините за специфический вопрос и отсутствие 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' (первая строка вывода classpath изменяется на/Users/me/projectDir/build/libs/gentreesrc-0.4.0.jar).Однако написание version = '0.2.0' не вызывает проблем (сборка не дает сбоя и работает, как ожидалось).

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

1 Ответ

1 голос
/ 28 апреля 2019

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

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

Обходные пути см. В Отслеживателе проблем Gradle .

...