アーティファクトプラグインを取得するための構成は次のとおりです。
buildscript {
repositories {
mavenCentral()
maven { url 'http://jcenter.bintray.com' }
}
dependencies {
classpath group:'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '3.0.1'
}
}
apply plugin:'com.jfrog.artifactory'
apply plugin:'ivy-publish'
...some publish spec stuff...
Gradle(2.3)を実行すると、次のようになります。
> Failed to apply plugin [id 'com.jfrog.artifactory']
> Cannot cast object 'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention@6b6c7be4' with class 'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention' to class 'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention'
確かにクラスパスの問題のように見えますが、私は文字通り、このプロジェクトと、これと同じgradle/artifactory構成のセットを使用する兄弟プロジェクトがあり、一方は機能し、もう一方は機能しません。どちらも同じトップレベルのプロジェクトの一部です。同じJDK(1.8.0_20)。同じGradle。すべて同じ。
私は困惑しています...
問題は、兄弟プロジェクトにさまざまなビットを追加したときに、buildscript {}セクションを定義する2つのプロジェクトがあったことでした。
buildscript {
...
dependencies {
classpath group:'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '3.0.1'
}
}
どうやらそれは依存関係の2つの異なるバージョンがクラスパスに存在する原因となったので、エラーが発生しました。
解決策は、buildscriptビットをマスタープロジェクトに移動して、これらの依存関係が1回だけ定義されるようにすることでした。
buildscript {
repositories {
maven { url "https://plugins.gradle.org/m2/" }
}
dependencies {
classpath group:'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '3.0.1'
}
}
別の潜在的な原因があります。これはすべて、クラスを定義するライバルのクラスローダーの問題のようです。完全修飾クラスにはローダーが含まれます。したがって、ロードAfoo.barはローダーBfoo.barではなく、分割する交差は、インターフェイスと注意深い定義を必要とする複雑なダンスです。
したがって、Jenkinsアーティファクトプラグインを使用してgradleアーティファクトプラグインを使用してgradleプロジェクトをビルドする場合は、usesPluginを追加する必要があります。そうしないと、jenkinsプラグインが初期スクリプトを生成してgradleプラグインをクラスローダーに追加します。
def server = Artifactory.server "artifactory"
def rtGradle = Artifactory.newGradleBuild()
rtGradle.usesPlugin = true // Artifactory plugin already defined in build script
...
私の問題は、デスクトップビルドはOK、jenkinsビルドはこの投稿の問題を示しています
私も同様の問題を抱えていました。 Gradleは、兄弟全体に手を差し伸べ、チェックまたは評価を行おうとしているようです。トップレベルのsettings.gradleに10個ほどのサブプロジェクトがあります。
私にとっての修正は、buildscriptブロックと依存関係をトップレベルのbuild.gradleに配置することでしたandそれぞれに配置します個々のサブプロジェクトは、必要に応じてbuild.gradleファイルを作成します。
これが機能する理由についての私の推測は、プラグインが親クラスローダーになる親にロードされ、各子プロジェクトがそのクラスローダーを継承して、下位の子スクリプトでの宣言がそのクラスローダークラスを使用し、CCEが発生しないことです。問題は、それらが同じクラスであるが、上部に何も宣言されていない場合、サブプロジェクトごとに異なるクラスローダーがあるため、割り当てることができないことです。これはGradle2.4で、IntelliJ14を使用していました。
現在受け入れられている回答はこの問題の原因を正しく特定していますが、個々のサブプロジェクトをビルドできる必要がある場合は、提案されたソリューションは機能しません(もちろん、ビルドスクリプトで定義されたリポジトリと依存関係にアクセスできなくなるため)。私のために働いた解決策は、私の各サブプロジェクトに同一ビルドスクリプトブロックを含めることでした。これが鍵のようでした。バリエーションがあると、元のエラーが発生します。
それが誰かを助ける場合に備えて、私は同じエラーを受け取りましたが、理由は異なります。
build.gradle
に次のものがありました。
dependencies {
classpath "org.jfrog.buildinfo:build-info-extractor-gradle:+"
}
依存関係に特定のバージョンが指定されていないため、ある時点で、アーティファクトプラグインはビルド中にバージョン3.xからバージョン4.xに更新されました。更新後、エラー(Could not find any convention object of type ArtifactoryPluginConvention
)が発生しました。
問題は、ビルドスクリプトの残りの構成が新しいプラグインバージョンで機能しないことだったと思います。バージョン3.xを使用するように依存関係を設定すると、問題が修正されました。
dependencies {
classpath "org.jfrog.buildinfo:build-info-extractor-gradle:3.+"
}