Backwards compatibility issue with Gradle 1.7

Old Forum
1

I’m attempting to upgrade from gradle 1.6 to gradle 1.7, and I think I’ve encountered a potential backwards compatibility issue.

I’m using the RPM plugin as follows:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.trigonic:gradle-rpm-plugin:1.3'
    }
}
   apply plugin: 'war'
 apply plugin: 'rpm'
  task rpm(type: Rpm, dependsOn: war) {
    packageName = "blah-${project.name}"
    version = "1.0.1"
    release = revision
    arch = NOARCH
    os = LINUX
   //more configuration, etc
}

Under gradle 1.6, this works fine, but if I run the same script with gradle 1.7, the build fails.

Stacktrace available here: https://gist.github.com/seanjreilly/6183722

At first glance it looks like a method has been removed from a gradle api class.

Cheers,

Sean

2

Already extensively discussed on dev list.

3

Yeah, that was me. I wasn’t sure which was the better place to discuss it, so I posted it twice.

Sorry about that.

4

I wouldn’t consider this a double-post, as most gradle users do not monitor the dev mailing list.

I do not know how many people utilize the rpm plugin, but for those that do, this at least gives them a public heads-up that they should expect an issue.

Core gradle is a great thing, but it is very similar to Jenkins, in that many users depend upon additional plugins to cover their entire workflow.

Maybe something could be added to the release notes in the known issues section that mentions that third-party plugins that rely upon internal copy classes likely will break because of the extensive refactoring done during this release, and the rpm plugin is known to have broken?

Once the plugin portal gets into place, ideally it would provide the ability to automatically run a smoke test of simply applying each plugin against new/maintained versions of gradle, and potentially take an uploaded set of tests associated with a plugin to check compatibility (possibly with the plugin describing expected ranges of compatibility).

-Spencer