JReleaser should support the Gradle Configuration Cache feature

[bitspittle]

More here: https://docs.gradle.org/current/userguide/configuration_cache.html

You can test a project by running gradle --configuration-cache help.

When I was trying this out on my own project, I ran into this message:

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

1 problem was found storing the configuration cache.
- Plugin 'org.jreleaser': registration of listener on 'Gradle.addBuildListener' is unsupported
  See https://docs.gradle.org/7.4/userguide/configuration_cache.html#config_cache:requirements:build_listeners

See the complete report at file:///home/d9n/Code/1p/kobweb/examples/helloworld/build/reports/configuration-cache/aie4zrn2laepsd7wcjs1fp0sf/u8pz4ts9wf2m4okvfuugzbw9/configuration-cache-report.html
> Listener registration 'Gradle.addBuildListener' by build 'kobweb' is unsupported.

I'm not 100% sure what JReleaser code looks like, but I recently changed some code in Kobweb that may help:

https://github.com/varabyte/kobweb/blob/main/gradle-plugins/application/src/main/kotlin/com/varabyte/kobweb/gradle/application/buildservices/KobwebTaskListener.kt

Here's the commit that introduced it: https://github.com/varabyte/kobweb/commit/161b227f978268b776322501d2aec2604f49d37a

For me, I was using the addTaskExecutionListener method to check if any task succeeded for failed. I was able to work around it by creating a service and using constructor injection to get access to a buildEventsListenerRegistry object:

class KobwebApplicationPlugin @Inject constructor(
    private val buildEventsListenerRegistry: BuildEventsListenerRegistry
) : Plugin<Project>
   ...
   val service = project.gradle.sharedServices.registerIfAbsent("task-state-listener", KobwebTaskListener::class.java) {
        parameters { ... }
    }
   buildEventsListenerRegistry.onTaskCompletion(service)

Hope that helps. Good luck!

[aalmiray]

Configuration cache is an incubating feature yet it fails the build when enabled and if it encounters issues ... will have to keep an eye on it.

[bitspittle]

Once I upgraded Gradle to 7.4 I think I started noticing Gradle bugging me about deprecated methods related to it (which I think will get yanked in 8.0?), which is why I went to learn about the configuration cache. Of course, I used their recommended APIs and now I'm getting a "You're using a feature which is incubating" instead of a "This is getting deprecated remove it NOW", so.... :shrug:

To be honest, I'm not sure I'm that happy with how I'm using build services. I may be using it wrong. Still, after I got things working locally, my "no-op" operations dropped from about 1 sec to half a sec. Not sure how it translates to bigger projects.

Still, their documentation isn't great, and I only got to what I got to after scouring Gradle forums and scant Google searches, so if you run into trouble when investigating this, feel free to ping me. Maybe I can save you a small bit of time and / or frustration.

[aalmiray]

Thanks. I used to be a big Gradle proponent for years but the churn of updating idioms and breaking changes between 5 and 7 got me down for the time being. Configuration cache is the latest bit that sounds quite interesting but certainly requires a bit more work to get to the level of quality that the rest of the tool has.

This being said, keeping a log of what's happening in the 7.x series and what's coming in 8.x is something I've got to do anyway, thanks for raising this issue.

[bitspittle]

Yeah, I hear you.

Ironically, in some ways, the Gradle API is finally becoming a better experience to work with, except for the fact now there's so much legacy "This method seems really convenient but don't use it" baggage. I could not believe version catalogs was something they only added in 7.3, as opposed to 1.0 or, in an attempt to be fair, 2.0.

There's just so many layers of sloppy original decisions that you have to sort through any time you want to figure out what you actually want to do today.

And, worse, this configuration cache issue is an example of them deprecating without realizing they should make sure they offer clear migration steps. If you follow the Gradle links about the "addBuildListener" deprecation to its ultimate end point, it's this: https://docs.gradle.org/7.4/userguide/build_services.html#operation_listener which barely explains anything and just throws you into extremely unhelpful, sparsely documented API code.

Anyway, I peeked at the JReleaser code and I'm pretty sure the code I wrote is the general shape that you'll need. So hopefully when you get to this issue later, at least that can save you maybe 2-3 hours of hunting around.... Feel free to ping me if that time comes, as I'd be happy to talk to you 1:1 through what I did.