Instructions for plain gradle incorrect

[xenoterracide]

plain gradle instructions are incorrect, they lead to this

given

plugins {
  `java-library`
  `java-test-fixtures`
  id("brix.bom")
  id("net.ltgt.errorprone")
  id("org.checkerframework")
}

dependencies {
  errorprone("com.google.errorprone:error_prone_core:2.+")
  annotationProcessor("com.uber.nullaway:nullaway:0.8.+")
  checkerFramework(checker.processor)
  compileOnly(checker.annotations)
  testFixturesCompileOnly(checker.annotations)
}

tasks.withType<JavaCompile>().configureEach {
  options.compilerArgs.addAll(
    listOf(
      "-parameters",
      "-Xlint:deprecation",
      "-Xlint:unchecked"
    )
  )
  options.errorprone {
    disableWarningsInGeneratedCode.set(true)
    excludedPaths.set(".*/build/generated/sources/annotationProcessor/.*")
    option("NullAway:AnnotatedPackages", "com.xenoterracide")
    val errors = mutableListOf(
    errors.add("NullAway")
    error(*errors.toTypedArray())
    ...

I get this error

> Task :util:compileTestFixturesJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':util:compileTestFixturesJava'.
> NullAway is not a valid checker name

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 5s
7 actionable tasks: 7 executed

[msridhar]

Which instructions are you referring to? It looks like in options.errorprone you don't have the line check("NullAway", CheckSeverity.ERROR), which is there in our README. Is your val errors = ... code equivalent to that?

[xenoterracide]

error("NullAway") does the same thing as what you're suggesting so yes, and I just created a PR ^ I just couldn't create the bug an PR at the same time, maybe I should have created them in the opposite order.

also, if what you're suggesting was the issue, NullAway shouldn't have even loaded ;), instead of not being a valid checker.

[xenoterracide]

btw, commented on the commit, but I am questioning my approach, maybe it would be better for the Nullaway documentation to just link to the gradle plugin documentation, since it covers everything and would be up to date with it.

[msridhar]

I think we should do a combination of linking to upstream documentation on the gradle plugin and having a self-contained working example that we explain, with the disclaimer that the plugin version may be out of date. I can update #467 when I get a bit of time

[lazaroclapp]

Just as a note, whatever instructions we end up giving, we should make sure that our sample projects use as similar a setup as we can, while still pulling the nullaway master (e.g. here), so that the instructions are CI tested. We should also be using the same version number for the plug-in in the README and in the dependencies for those sample projects and our own code.

I also think, because of those CI tests, that our instructions should work with the gradle plug in version indicated in the README, but the underlying issue might be that we ought to update that version in both our own build and the docs 🙂

[ben-manes]

I'd recommend switching the documentation to using Thomas' gradle-nullaway-plugin. You can see my real-world example which is similar to the above snippet.

[xenoterracide]

@ben-manes I have to be honest I don't understand the reason for that plugin, doesn't seem hard to enable nullaway without it.