Skip to content

Project Isolation support #144

@ZakTaccardi

Description

@ZakTaccardi

To apply the plugin to all Gradle projects, you only need to apply the plugin to the top-level build file as shown above

With regards to project isolation support (docs), this seems to be a bit of a problem. One project should not access another project.

target.allprojects {
it.applyToProject(providers, agents)
}

Above, the root project is accessing other projects. I somewhat solve this problem by having separate plugins:

com.myPlugin.aggregator
com.myPlugin.subproject

com.myPlugin.subproject is applied to subprojects, and com.myPlugin.aggregator is responsible for aggregating the output from subprojects that apply com.myPlugin.subproject.

Excerpt from Square's herding elephants article on why this feature is important

Eliminate cross-project configuration (think: allprojects and subprojects) so that every module (or "project", to use Gradle terminology) could be configured independently from every other. This should improve the configuration phase of the build, since those APIs defeat configuration on demand; and it also sets us up to be compatible with a new experimental Gradle feature known as project isolation, which holds the promise of making slow Android Studio syncs a thing of the past.

Even though Project Isolation is experimental (and in most cases, not yet practical) - it's important that Gradle plugins (like Kover) design with Project Isolation in mind. For example, having separate plugins and only using allprojects/subprojects { } (if you must) in a dedicated .aggregator plugin. That way, when Gradle releases APIs to avoid the allprojects/subprojects { } APIs, the migration is trivial.

note: I'd definitely recommend reaching out to the Gradle team to see what they recommend here

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions