Hey folks! We released a new version of the Plugin Publishing Plugin today. Starting with 2.1.0, you can declare your plugin's compatibility with Gradle features. For now, it's only the configuration cache; more will follow later. CC-compatible plugins will be promoted in the search results. We hope this will help the community become more aware of these features and, in particular, accelerate the widespread adoption of configuration cache, making everybody's builds faster. Please share your feedback! Here's how it looks:

Too bad that this means we'll have to publish a new version only to have the badge. Could there be a way to add the badge to existing plugins/versions without publishing a new version?

Yes, you can drop a request to https://github.com/gradle/plugin-portal-requests/issues or plugin-portal-support@gradle.com

the docs: https://plugins.gradle.org/docs/publish-plugin#declaring-compatibility

It'd be nice to be able to declare 'qualified' support, rather than a boolean yes/no. For example, KGP supports Project Isolation for JVM and Native targets, but not JS or WasmJS.

t'd be nice to be able to declare 'qualified' support, rather than a boolean yes/no. For example, KGP supports Project Isolation for JVM and Native targets, but not JS or WasmJS.

We've considered this at some point, but concluded that partial support would be confusing to reason about. Note that you can't declare compatibility with Isolated Projects, because it's not stable yet. Once it becomes incubating, we'll add an option to declare it as well. By this time, hopefully, there would be no major blockers for KGP to deliver the full support.

For comparison, there's community site that shows compatibility with AGP9 and Project Isolation, and both as a user and plugin author it's been useful to get more specific info and links to related issues. I'm not confused by it. https://agp-status.frybits.com/gradle-project-isolation/ https://agp-status.frybits.com/agp-9.0.0/

Could you add a options to declare support for the Provider API and Build Cache? As a plugin user those are often what I'm most interested in!

Thanks for the suggestion! We are considering it, but we need some time to define more formally what it means for plugin to support Build Cache)

As an FYI, I had added a page for plugins compatible with Gradle Isolation: https://agp-status.frybits.com/gradle-project-isolation/ I'm open for other pages to be added here for compatibility tracking of Gradle features (like CC). PRs are welcome!

@Pablo Baxter, would you consider renaming the page to match the name of the feature in Gradle --

Isolated Projects

?

Yes, but the url path will have to remain and be a redirect. I'll work on that change later today.

Seems to work great!

I'm surprised this new feature requires an import

import org.gradle.plugin.compatibility.compatibility

Is that intentional and desired? I try to avoid import statements in my build scripts.

@tony for now, yes. In the future, we may consider including this functionality into Gradle core so the experience is smoother, but we think it's too early for that now.

actually... why isn't Gradle's Kotlin DSL capabilities generating typesafe accessors for this? Has this plugin been developed in such a way to prevent that, either unintentionally or by design?

Kotlin DSL only generates typesafe accessors for project-level extensions, configurations and tasks: https://github.com/gradle/gradle/blob/c83e236569625054308e0a4886daed90a30c2ad4/pla[…]-dsl/src/main/kotlin/org/gradle/kotlin/dsl/accessors/Emitter.kt It won't look at extensions on tasks, or extensions on other extensions. And even if it did, in this case this is an extension on an element in a container property of an extension, and that container is empty by default.

@tony Can you share a bit more about what you meant by typesafe accessors, please? I agree with @Thomas Broyer. There's one extra possibility: put the extension function into

org.gradle.kotlin.dsl

, but we haven't considered it yet