tbroyer/gradle-errorprone-plugin-v0.0.x

Gradle 2.4-rc-1

ben-manes opened this issue · 6 comments

Fyi,

I switched to nightly to provide some info for the Gradle team, and my build broke due to an incompatibility.

Caused by: java.lang.NoSuchMethodError: org.gradle.api.tasks.compile.JavaCompile.setToolChain(Lorg/gradle/jvm/toolchain/JavaToolChain;)V
    at net.ltgt.gradle.errorprone.ErrorPronePlugin$1.execute(ErrorPronePlugin.java:20)
    at net.ltgt.gradle.errorprone.ErrorPronePlugin$1.execute(ErrorPronePlugin.java:17)

Verified that the plugin is incompatible with 2.4-rc-1.

Thanks for the heads up. I was waiting for an RC to work further on it since many things changed since 2.3.

I just pushed an update for 2.4-rc-1 (that starts to look more haskish than ever as Gradle adds more levels of indirection), let me know how it works for you. I'll only cut a release when the 2.4 final release is there though.

Works great, thanks!

Gradle 2.4 is here, so I released 0.0.7.

I also moved to the plugin portal (not really sure it's a good thing; we're losing snapshots, unless I somehow continue to push those to OSSRH) so that means:

  • Gradleware has to approve the plugin before it's available (shouldn't take more than one or two days), as I decided to keep the same groupId.
  • the maven repository will (obviously) change.

Eventually, instructions to use the plugin should be available from https://plugins.gradle.org/plugin/net.ltgt.errorprone

You should change the example to use the portal id, apply: 'net.ltgt.errorprone', or they may mistakenly reject it. As bintray is a Maven Central mirror and optionally supports bi-directional sync, there isn't a requirement for a repository change by users.

You can have travis-ci push snapshots on every successful build, which removes the hassle.