search

kelloggm / checkerframework-gradle-plugin

Gradle plugin to use the Checker Framework for Java
Apache License 2.0
66 stars 15 forks source link

Crash during Gradle configuration with version check enabled #108

Open msridhar opened 4 years ago

msridhar commented 4 years ago

To reproduce, clone https://github.com/msridhar/obj-cons-autovalue-example and do:

git checkout a6a5384d3d29bc8cbe4c2a1da1223af0921850b6
./gradlew --dry-run

I get the following output:

> Configure project :
Unable to determine Checker Framework version. Assuming default is being used.

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'obj-cons-autovalue-example'.
> No signature of method: org.gradle.internal.logging.slf4j.OutputEventListenerBackedLogger.debug() is applicable for argument types: (java.util.zip.ZipException) values: [java.util.zip.ZipException: zip file name too long]
  Possible solutions: debug(java.lang.String), debug(java.lang.String, [Ljava.lang.Object;), debug(java.lang.String, java.lang.Object), debug(java.lang.String, java.lang.Throwable), debug(org.slf4j.Marker, java.lang.String), debug(java.lang.String, java.lang.Object, java.lang.Object)

The problem is fixed if we add skipVersionCheck = true to the checkerFramework block; see commit https://github.com/msridhar/obj-cons-autovalue-example/commit/d9f8c7f61fb03a1a307f9c2bfbb9ebbbc56a9575.

Not sure if this is a Gradle plugin bug or a CF bug.

kelloggm commented 4 years ago

Definitely a gradle plugin bug. These bugs are the reason why the skipVersionCheck option exists.

The root cause is that one of the ways we try to determine the CF version is by reading the actual checker.jar file's metadata (this is a fallback method, but it ends up being used fairly often). That involves unzipping the jar, which fails if the file name is too long (as you can see from the exception, that's what happened here). The workaround, as you discovered, is to use skipVersionCheck = true.

Sorry you ran into this. I'm going to leave the issue open because the failing repo will be useful to test on if we ever think we can fix this.

msridhar commented 4 years ago

Ah right I see this is already documented. In any case good to have an open issue about it.

Is it a particular API call that fails when the file name is too long? Could we just copy the jar file to a temp directory (which presumably will have a shorter path) and unzip that copy?