0.3.0 Always Crashes

[herriojr]

Hi, I noticed when I updated to 0.3.0, each time I try and run the gradle command to either check or update, I get the following error:

Execution failed for task ':mymodule:metalavaGenerateSignatureForPartnersRelease'.
> A failure occurred while executing me.tylerbwong.gradle.metalava.worker.MetalavaWorkAction
   > Process 'command '/Library/Java/JavaVirtualMachines/jdk-15.0.2.jdk/Contents/Home/bin/java'' finished with non-zero exit value 255

I'm on OS X 12.5.1 and of course, it's using jdk-15.0.2.jdk

It seems at some point, either the plugin or metalava itself stopped supporting already broken APIs. I have a legacy API that I'm trying to fix to not expose things that should not be exposed. For example, there are classes that should be hidden that are technically exposed as public via methods in the public api. In previous version of the plugin, namely 0.2.1, this wasn't an issue. I could create the signature file with the hidden classes included without issue. Unfortunately, in 0.3.0, this seems to no longer be the case. Was this something metalava changed or was this something the plugin changed?

To reproduce, do something like:

metalava {
    hiddenPackages.add("my.test.hidden")

my.test.hidden.Test

class Test {}

my.test

class RealTest {
    fun exposedButReallyShouldntBe(test: Test)
}

In the previous version, it would initially fail an api check, but as soon as I generated the signature file, it would stop. In the 0.3.0 version, it will fail both an api check as well as a signature check.

[tylerbwong]

Hm, that is a little concerning considering we just migrated to Gradle's Worker API in #35. Would you be able to provide any other logs (.log)? Or rerun with --stacktrace? I haven't been able to reproduce this myself, although majority of my projects are on JDK 11.

[herriojr]

@tylerbwong I'm able to reproduce w/ just using the raw metalava command using the arguments the plugin supplies. For the case of generating the signature, I was able to fix it with --pass-baseline-updates, however, I don't fully understand the flag. Basically, I think metalava changed it so the default is to fail both the check and signature generation if anything is an ERROR, even if it exists in the previous api.txt file whereas before you could get it to add an ERROR to the api.txt and that would cause it to be ignored in the subsequent check call. I'll try and roll a simple example project and make a PR out of it.

[herriojr]

@tylerbwong I'm actually going to just close this as I was able to get all errors removed for myself and I'd like to not accept errors to be added back in.