Skip to content

Introduce Support for Gradle Isolated Projects#71

Open
findyourexit wants to merge 1 commit into
iurysza:mainfrom
findyourexit:findyourexit/support-isolated-projects
Open

Introduce Support for Gradle Isolated Projects#71
findyourexit wants to merge 1 commit into
iurysza:mainfrom
findyourexit:findyourexit/support-isolated-projects

Conversation

@findyourexit

@findyourexit findyourexit commented Jun 30, 2026

Copy link
Copy Markdown
Contributor

🚀 Description

This PR contains the following changes:

  • Reworked graph generation to gather each project's dependencies from within its own context, dropping the configuration-time project.allprojects access that Isolated Projects disallows.
  • Added a dev.iurysouza.modulegraph.settings settings plugin - the one-line way to wire module-graph into a multi-project build under Isolated Projects.
  • Moved graph assembly to task-execution time, backed by a serializable per-project snapshot and a shared build service, so things stay Configuration Cache friendly too.
  • Bumped the plugin-build Gradle version 8.9 -> 8.11.1 for the Isolated-Projects-safe ProjectDependency.getPath().
  • Documented it all in the README.md and switched the sample build over to the settings plugin.

One behavioural note: applying the plugin to a single project still graphs that project and its dependencies, but aggregating a whole multi-project build now goes through the settings plugin, since the old allprojects traversal isn't possible under Isolated Projects. Existing multi-project setups would adopt the one-line settings plugin to keep getting the full graph (hence the breaking-change flag below).

📄 Motivation and Context

This PR isn't targeting an open issue, but it's something I kept running into while adopting Gradle's Isolated Projects across a handful of my own multi-module projects: any build that turned it on and applied module-graph would fail outright, so I'd had to pull the plugin out to make progress.

I'd much rather keep it around (the module graphs are genuinely useful day to day) so these changes teach module-graph to play nicely with Isolated Projects (and the Configuration Cache).

🧪 How Has This Been Tested?

I added a functional test that drives createModuleGraph across a multi-project build with --configuration-cache and Isolated Projects enabled, asserting the graph comes out correct, that there are no configuration-cache problems, and that a second run reuses the cache.

Beyond that, the existing suite still passes (along with ktlintCheck, detekt and validatePlugins), and I ran it against the sample build locally - the Configuration Cache entry stores then reuses, and the graphs regenerate identically. All on a JDK 8 toolchain (Azul Zulu) with Gradle 8.11.1.

📦 Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

✅ Checklist

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.

Previously the plugin read every sibling project's state at configuration time through `project.allprojects` and a querier that reached into other projects' configurations, dependencies and plugins, which is incompatible with Gradle's Isolated Projects. The graph is now assembled from per-project snapshots, each collected from within its own project, so no cross-project access happens at any point and the plugin is compatible with both the Configuration Cache and Isolated Projects.

- Add `ProjectInfo`, a serializable per-project snapshot of a project's path, applied plugin ids, external dependency coordinates and declared project dependencies.
- Add `ModuleGraphRegistry`, a build-scoped service that aggregates the snapshots, and `ModuleGraphContributeTask`, which registers a project's snapshot at execution time so it survives configuration-cache reuse.
- Add the `dev.iurysouza.modulegraph.settings` settings plugin for one-line multi-project adoption: it applies the plugin to the root project and makes every other project contribute a snapshot that the root `createModuleGraph` task depends on.
- Replace `GradleProjectQuerier` with `SnapshotProjectQuerier` and move graph parsing into the task action, so the model is built from the collected snapshot instead of live `Project` instances.
- Collect each snapshot through a lazy provider instead of `afterEvaluate`, and resolve module types from the captured data via a pure `resolveModuleType`.
- Bump the plugin build to Gradle 8.11.1 for the Isolated-Projects-safe `ProjectDependency.getPath()`.
- Add a functional test that runs `createModuleGraph` with the configuration cache and Isolated Projects enabled across a multi-project build and asserts a correct, cache-reusable result.
- Document the support in the README and dogfood the settings plugin in the sample build, configuring it from the root build and targeting the sample readmes.
@findyourexit
findyourexit force-pushed the findyourexit/support-isolated-projects branch from 2ecda14 to baa44e1 Compare June 30, 2026 07:18
@iurysza

iurysza commented Jun 30, 2026

Copy link
Copy Markdown
Owner

Hi there! Thanks for submitting. I'll run some reviews on it and take a look before EOW. Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants