feat(pkl-gradle): Implement gradle configuration cache support

[ffluk3]

Fixes #1425

Gradle's configuration cache is one of the more impactful performance features in modern Gradle. It serializes the task graph after the first configuration phase so subsequent builds can skip it entirely. For large projects this can mean the difference between a multi-second configuration overhead and near-instant task scheduling.

The root cause preventing pkl-gradle from adopting the configuration cache was a handful of patterns the configuration cache explicitly prohibits: holding a reference to the Project object in a plugin field, accessing getProject() inside task action code at execution time, and caching CLI option objects that close over non-serializable state. These patterns work fine in a standard Gradle build, but they prevent Gradle from safely serializing the task graph to disk.

What changed

PKL Plugin rework

The most visible structural change in PklPlugin is the removal of the @LateInit private Project project field. Rather than storing the project on the plugin instance, it's now passed as a parameter through the configure call chain. This is a mechanical but pervasive refactor, since every configure* method gains a project argument and passes via property drilling.

Per-task changes

• BasePklTask captures project.getLayout().getProjectDirectory() at configuration time into a getWorkingDir() DirectoryProperty, rather than calling getProject().getProjectDir() at execution time. CliBaseOptions is now constructed fresh each time it's needed inside a task action, which is a trade-off between the (potentially negligible) cost of construction, and caching it, which would require holding a cross-boundary reference that defeats the configuration cache.
• EvalTask's lazily-cached Provider<CliEvaluator> is similarly replaced with a factory method, and JavaCodeGenTask and KotlinCodeGenTask leverage the output dir.
• In ModulesTask, getTransitiveModules() changes from a ListProperty<File> to a ConfigurableFileCollection (enabling .from() wiring rather than .set()), and gains a @PathSensitive(ABSOLUTE) annotation so the task doesn't unnecessarily re-run when files are moved between machines but their content and paths are unchanged. The parsedSourceModulesCache map is also removed — it was there to avoid redundant parsing but is incompatible with the cache since it holds mutable state across invocations.

Cleanup

The AnalyzeImportsTask no longer wraps CliImportAnalyzer construction in a lazily-cached Provider; instead it constructs the analyzer inline inside doRunTask(), consistent with the other task types. The transitive-import parsing logic in PklPlugin and PluginUtils is unchanged.

Tests

Each task type gets a new is configuration cache compatible test that runs the task twice with --configuration-cache and asserts that the first run stores a cache entry and the second reuses it. The test infrastructure for this lives in a new runTaskWithConfigurationCache helper on AbstractTest. NOTE: these tests run slightly slower than the rest of the suite because they need the forked Gradle process to execute twice to prove out configuraion cache usage.

[HT154]

Thanks! Just one little nit.

This seems reasonable to me, but I'm going to defer to @bioball's greater Gradle expertise for final approval.

[ffluk3]

Good morning @bioball! Please let me know if there are other requests or questions around getting this verified or merged in. Happy to help out where I can!

[bioball]

Hi! This is on my list of TODOs. I haven't forgotten about it! Apologies, my availability is quite limited right now so I haven't gotten to a review yet.

[ffluk3]

No problem at all! Appreciate both of your time managing and maintaining the project 😄

[bioball]

Thanks for this! This mostly looks great. I have just a few comments.

Also, would love some eyes from @netvl, who wrote much of the code in our Gradle plugin.

[ffluk3]

Thanks @bioball! All feedback should be addressed now 😄

[bioball]

LGTM, thanks! This looks great! I'll wait to see if @netvl wants to provide some comments before merging this.

Some small nits to fix.

[ffluk3]

LGTM, thanks! This looks great! I'll wait to see if @netvl wants to provide some comments before merging this.

Some small nits to fix.

Thanks! Feedback incorporated and I squashed to a single commit.

[netvl]

Just a couple of questions, overall looks awesome!

[ffluk3]

Just a couple of questions, overall looks awesome!

@netvl thanks for your review! I was able to roll back my null checks, plus some more helpful exception messages on missing sourcesets.

[ffluk3]

Hey @bioball thanks for merging this! It was great to collaborate to get this update in.

Quick question on the release cadence: I know your minor revisions will be frequently deployed Feb/Jun/Oct per your roadmap. Having said that, will there be any plans to cut this change (and the existing merged) as a patch before June? Our team is excited to make use of this enhancement!

Thanks again.

[bioball]

We generally don't put behavior changes into patch versions. So, alas, this change will be part of the 0.32 release cycle!