Gradle плагин artifactory, говорящий "Нельзя бросать объект" org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention '... "

Ответ 1

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

buildscript {
    ...
    dependencies {
        classpath group:'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '3.0.1'
    }
}

Очевидно, это привело к тому, что в пути к классам существовали две разные версии зависимости, отсюда и ошибка.

Решением было переместить бит buildscript в главный проект, чтобы эти зависимости были определены только один раз:

buildscript {
    repositories {
        maven { url "https://plugins.gradle.org/m2/" }
    }
    dependencies {
        classpath group:'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '3.0.1'
    }
}

Ответ 2

Вот еще одна потенциальная причина. Все это похоже на проблему с конкурирующими загрузчиками классов, определяющими класс. К полным классам относятся погрузчик. поэтому, load A foo.bar не является загрузчиком B foo.bar и пересекает это разделение - это сложный танец, требующий интерфейсов и тщательного определения.

Итак, при использовании плагина Jenkins artifactory для создания вашего проекта gradle с плагином gradle artifactory, вы должны добавить плагин usesPlugin или jenkins, будет генерировать init script, который добавит плагин gradle к загрузчик классов.

def server = Artifactory.server "artifactory"
def rtGradle = Artifactory.newGradleBuild()
rtGradle.usesPlugin = true // Artifactory plugin already defined in build script
...

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

Ответ 3

Я получал подобное исключение при создании с Дженкинсом. Для меня конфликт был с версией Jenkin и версией в Build script:

Чтобы решить эту проблему, в разделе Artifactory сборки есть флаг, который вы можете проверить, указав, что вы хотите использовать версию из файла gradle:

Это исправило мою проблему. Надеюсь, что это поможет.

Ответ 4

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

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

Мое предположение о том, что это работает, заключается в том, что плагин загружается в родительский элемент, который будет родительским загрузчиком классов, тогда каждый дочерний проект наследует этот загрузчик классов таким образом, что объявление в нижнем дочернем script использует класс classloaders и CCE не происходит. Проблема в том, что они являются одним и тем же классом, но не назначаются, поскольку разные загрузчики классов на подпроект, если ничто не объявлено в верхней части. Это было Gradle 2.4 и с использованием IntelliJ 14.

Ответ 5

В случае, если это помогает кому-то, я получил ту же ошибку, но по другой причине.

У меня было следующее в build.gradle:

dependencies {
    classpath "org.jfrog.buildinfo:build-info-extractor-gradle:+"
}

В какой-то момент плагин artifactory обновил себя от версии 3.x до версии 4.x при построении, потому что для зависимости не была указана конкретная версия. После обновления я получил ошибку (Could not find any convention object of type ArtifactoryPluginConvention).

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

dependencies {
    classpath "org.jfrog.buildinfo:build-info-extractor-gradle:3.+"
}

Ответ 6

Хотя принятый в настоящее время ответ правильно определяет причину этой проблемы, предлагаемое решение не работает, когда вам все еще нужно иметь возможность создавать отдельные подпроекты (поскольку тогда, конечно, они больше не имеют доступа к репозиториям и зависимостям, определенным в buildscript). Решение, которое сработало для меня, состояло в том, чтобы в каждом из моих подпроектов были одинаковые блоки buildscript, что казалось ключевым. Любые изменения могут привести к первоначальной ошибке.