search

melix / jmh-gradle-plugin

Integrates the JMH benchmarking framework with Gradle
Apache License 2.0
659 stars 88 forks source link

jmhJar task is not compatible with Gradle configuration cache #229

Closed shoaniki closed 6 months ago

shoaniki commented 1 year ago

Describe the bug The plugin causes an error if the experimental Gradle configuration cache is enabled.

To Reproduce Run gradle jmh --configuration-cache in a project that uses this plugin.

The output will include an error along the lines of:

FAILURE: Build failed with an exception.

* What went wrong:
Configuration cache problems found in this build.

1 problem was found storing the configuration cache.
- Task `:project:jmhJar` of type `org.gradle.api.tasks.bundling.Jar`: cannot serialize object of type 
'org.gradle.api.internal.project.DefaultProject', a subtype of 'org.gradle.api.Project', as these are not
supported with the configuration cache.
  See https://docs.gradle.org/7.6-rc-3/userguide/configuration_cache.html#config_cache:requirements:disallowed_types

This appears to happen for both shadow and non-shadow forms of the jar task.

There's an easy and obvious workaround, of course -- "don't do that" -- but it becomes a chore if the configuration cache is turned on in gradle.properties.

asarkar commented 1 year ago

Gradle configuration cache is a rushed, ill-designed and half-baked feature that is incompatible with many of Gradle's own existing APIs. See https://github.com/gradle/gradle/issues/18520

melix commented 1 year ago

Can you provide a reproducer? Which version of the plugin are you using? I pushed a test which passes.

jjohannes commented 7 months ago

This problem still exists. I am not 100% sure yet, but I assume that it is related to the project.zipTree here:

https://github.com/melix/jmh-gradle-plugin/blob/0d1e7a8e7c8a69c0c3862879031459966c9f8a01/src/main/groovy/me/champeau/jmh/JMHPlugin.groovy#L280

While it should be okay to use zipTree here I think, it might be an issue with how this is routed (is it Project.project or Task.project?) in dynamic Groovy. Maybe that's why it work sometimes (in the test) but not in all user scenarios. But that's only a guess, because I see nothing else in there that might cause this. Here is the report:

config_cache

jjohannes commented 7 months ago

I don't know why the tests do not reproduce this, but all my manual testing indicate that it is a general problem: it is not possible to access project.zipTree in this mapping context, which is (presumably) executed close to execution time. Which somehow makes sense, as the actual files are not always available during configuration time yet.

Maybe there is a simpler way to get the ArchiveOperations service, but this is the "simplest" fix I could come up with: #261