36

Here's the configuration to get the artifactory plugin:

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...

I run gradle (2.3) and I get:

> 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'

Certainly looks like a classpath issue, but I literally have this project and a sibling project using this same set of gradle/artifactory configurations and one works and the other does not. Both are part of the same top level project. Same JDK (1.8.0_20). Same Gradle. Same everything.

I'm baffled...

Chris Kessel
  • 5,583
  • 4
  • 36
  • 55

7 Answers7

24

The problem was that when I added the various bits to the sibling project that meant I had two projects defining the buildscript {} section. 

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

Apparently that caused two different versions of the dependency to exist in the classpath, hence the error.

The solution was to move the buildscript bit into the master project so those dependencies are only defined once:

buildscript {
    repositories {
        maven { url "https://plugins.gradle.org/m2/" }
    }
    dependencies {
        classpath group:'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '3.0.1'
    }
}
M. Justin
  • 14,487
  • 7
  • 91
  • 130
Chris Kessel
  • 5,583
  • 4
  • 36
  • 55
  • 2
    I can't upvote this enough. Just spent the last hour throwing my face at this. Not to mention this post wasn't getting indexed by google for some reason. Thanks!!! – WillBD Jul 31 '15 at 20:07
  • Yea, I spent nearly a day commenting lines in and out until I finally figured it out. Really glad I could pass on the knowledge! – Chris Kessel Aug 04 '15 at 17:01
  • 1
    funny. I only see this when running with jenkins + artifactory plugin and not in desktop. They have an init script, and I wonder if it does the double apply problem. Sure does look like dueling classloaders – Peter Kahn Oct 05 '17 at 19:22
  • My understanding is simply that sibling projects needed to have identical dependencies {} sections – Arnie Schwarzvogel Mar 27 '18 at 15:32
  • It looks like this solution was discussed on the Gradle forums: http://forums.jfrog.org/Gradle-plugin-and-multi-projects-td7580521.html – M. Justin Aug 22 '18 at 20:01
  • When subprojects have the same buildscript dependencies Gradle will attempt to reuse an existing class loader presumably for performance reasons. When they do not a different class loader is used for each gradle file loaded (which includes subprojects) resulting in the potential to have conflicting types. This is why you can get away with adding the build-info-extractor-gradle to the classpath in multiple subproject buildscript blocks if the subproject buildscript dependencies are all the same. – MarkRx Nov 04 '20 at 02:02
  • Since [Gradle 3.0](https://docs.gradle.org/3.0/release-notes.html#improved-plugins-dsl) it is possible to [apply external plugins with the same version to subprojects](https://docs.gradle.org/current/userguide/plugins.html#sec:subprojects_plugins_dsl) which seems to solve the casting issue described in the original question with minimal repetitions in the build scripts. – Attila T Aug 13 '21 at 12:39
12

Here's another potential cause. All of this looks to be a problem with rival classloaders defining the class. The full qualified classes include the loader. so, load A foo.bar is not loader B foo.bar and crossing that divide is a complex dance requiring interfaces and careful definition.

So, when using the Jenkins artifactory plugin to build your gradle project with the gradle artifactory plugin, you must add the usesPlugin or jenkins plugin will generate an init script which adds the gradle plugin on to a class loader.

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

My problem was, desktop build OK, jenkins build shows this post's problem

Peter Kahn
  • 12,364
  • 20
  • 77
  • 135
  • this is a life save. After checking "Project uses the Artifactory Gradle Plugin" checkbox on jenkins job configure, job has been passing – Emily Jan 25 '21 at 16:18
6

I was getting a similar exception when building with Jenkins. For me the conflict was with Jenkin's version and the version in the Build script:

Jenkins Build Error

To address this the Artifactory section of the build has a flag you can check specifying that you want to use the version from the gradle file:

Flag to fix issue

This fixed my issue. Hope it helps.

nwallman
  • 502
  • 7
  • 14
  • But this doesn't allow me to override the Artifactory credentials using Jenkins CI. This is also mentioned in the doc - https://github.com/jfrog/project-examples/tree/master/gradle-examples#:~:text=Project%20uses%20the%20Artifactory%20Gradle%20Plugin – RDK May 11 '23 at 04:36
3

I had a similar problem. Gradle seems to try to reach across and do some checking or evaluation across siblings. I have a top level settings.gradle with 10 or so subprojects.

The fix for me was to put the buildscript block and dependencies at the top level build.gradle and put it in each of the individual subprojects build.gradle files where needed.

My guess as to the reason this works is that the plugin gets loaded in the parent which will be a parent classloader, then each child project inherits that classloader such that the declaration in the lower child script uses that classloaders class and CCE does not occur. The problem is they are the same class, but not assignable since the different classloaders per subproject if nothing is declared at the top. This was Gradle 2.4, and using IntelliJ 14.

Randy
  • 729
  • 5
  • 14
2

In case it helps someone, I got the same error, but for a different reason.

I had the following in my build.gradle:

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

At some point the artifactory plugin updated itself from version 3.x to version 4.x while building, because no specific version was specified for the dependency. After it updated I got the error (Could not find any convention object of type ArtifactoryPluginConvention).

I guess the problem was that the rest of the configuration in my build script doesn't work with the new plugin version. Setting the dependency to use version 3.x fixed the problem for me:

dependencies {
    classpath "org.jfrog.buildinfo:build-info-extractor-gradle:3.+"
}
avivr
  • 1,393
  • 15
  • 28
1

While the currently accepted answer correctly identifies the cause of this issue, the proposed solution doesn't work when you still need to be able to build individual subprojects (because then of course they no longer have access to the buildscript defined repositories and dependencies). The solution that worked for me was to have identical buildscript blocks in each of my subprojects, that seemed to be the key. Any variations would cause the original error.

Endareth
  • 492
  • 3
  • 15
  • exactly the same here. this is super weird. I have to add an unnecesary dependency into the buildscript of a subproject, just because of this. – lqbweb Dec 09 '19 at 15:12
0

I got the same exception thrown by bamboo:

'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention@18eb2827' with class 'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention' to class 'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention'

Since the bamboo Bamboo Artifactory Plugin by default looks for the gradle.propeties file in each sub-project module, it has to be provided there.

There is no need for publishing logic in the build.gradle file since the Bamboo Artifactory plugin will read the gradle.properties file for each module respectively, containing:

group=com.example
artifactId=your-project
version=1.0.0

The reason that I got the ArtifactoryPluginConvention exception thrown was that my configured build plan on Bamboo was misconfigured.

With misconfigured, the build ordered of the tasks was not correct. Have a look at your bamboo building tasks/preferably clone a Bamboo plan that is already working.

bluecheese
  • 41
  • 3