Hey folks! 👋 Plugin authors can now declare that their plugins are compatible with Isolated Projects when publishing to the Plugin Portal. When declarations for Configuration Cache landed in March (announcement), we promised more features would follow. Starting with Plugin Publish Plugin 2.2.1, you can add

isolatedProjects

right next to `configurationCache`:

gradlePlugin {
    plugins {
        create("myPlugin") {
            id = "io.github.my.plugin"
            // ...
            compatibility {
                features {
                    configurationCache = true
                    isolatedProjects = true
                }
            }
        }
    }
}

Before enabling Isolated Projects, most users first want to know whether their plugins support it. A declaration answers that on your plugin's page and can help your plugin in search results. Declaring

false

is useful too -- there's no penalty for it. All you need is the new Plugin Publish Plugin version, no Gradle upgrade required. We've also covered it in the Gradle 9.8.0 release notes, out today, and in the user manual: • Release notes: Declaring plugin compatibility with Isolated Projects on the Plugin Portal • User manual, with Kotlin and Groovy snippets: Declaring compatibility with Gradle features • New to Isolated Projects? Start here: Isolated Projects A few things to know: • In the Kotlin DSL,

compatibility

needs `import org.gradle.plugin.compatibility.compatibility`; in Groovy, it's

compatibility(it) { ... }

. • While Isolated Projects is incubating, the declaration shows up in the compatibility table on your plugin's page, marked "(Incubating)", but not as a badge at the top yet. • Isolated Projects constraints may get stricter before the feature is stable, so treat the declaration as something to revisit. Questions and feedback are welcome here or in #C0BJEV93WMA

saw that and immediately adopted it 🙂

If you are testing plugins with GradleTest you can do

gradleTestSets {
  testSets {
    main {
      isolatedProjects.mode = 'fail' // or another mode
    }
  }
}

If the Gradle version under test does not support it, it will print a warning and ignore the parameter.

this is another thing where the portal does nothing to validate the claim, right? It's on the plugin author to do their due diligence and test their plugin? I'm asking because I've had issues in the past where I thought I was IP-compatible, but it turned out some Gradle API I was using was backed under the hood by a

project

instance and this was violating the (pre-incubating) IP contract. I'm honestly not sure I've resolved all of those. However, my tests now run with the IP flag on and there are no reported issues. Is that good enough?

Well @tony , I just caught out on that today. Had a bunch of tests and one IP-case still slipped through. And the worst of it was that the bug was actually inside Grolifant. Had to release an urgent fix, now I'm scratching my head on how it slipped past.

scratching my head

I feel this

imo if you have functional tests that are enabling configuration cache or isolated projects then you should flag those compatibilities as true in the plugin portal

@Josh Friend That is what is being practiced, but still...