FIX: Move plugin-builder to composite build

[Daniel-ADFA]

No description provided.

[coderabbitai]

📝 Walkthrough

Release Notes: FIX - Move plugin-builder to composite build

Changes

• Restructured plugin-builder as composite build - Moved plugin-api/plugin-builder from a subproject to an independent composite build included via pluginManagement in the root settings.gradle.kts
• Updated plugin artifact resolution - Modified app/build.gradle.kts to source the plugin-builder JAR from the included build (gradle.includedBuild("plugin-builder").task(":jar")) instead of the subproject dependency
• Added plugin-builder Gradle settings - Created new plugin-api/plugin-builder/settings.gradle.kts to configure the composite build with its own dependency repositories (Google, Maven Central, Gradle Plugin Portal)
• Changed JAR source path - Updated the input source for plugin artifacts from project-relative path to a fixed file path (rootProject.file("plugin-api/plugin-builder/build/libs/plugin-builder-1.0.0.jar"))

⚠️ Risks and Best Practice Concerns

• Hard-coded version string - The JAR filename contains a hard-coded version (plugin-builder-1.0.0.jar), which could cause failures if the version is updated without modifying this reference
• Brittle hard-coded file path - Using rootProject.file() with a fixed build directory path is fragile and tightly couples the build configuration to the directory structure; consider using the Gradle API to resolve the JAR dynamically from the composite build
• Increased build coupling - Composite builds introduce an additional layer of build coordination that can be more difficult to debug and maintain compared to subproject dependencies
• Potential build order dependencies - Composite builds may not guarantee the same dependency ordering as subprojects, which could lead to intermittent build failures

Walkthrough

The changes convert the plugin-builder module from a standard Gradle subproject to a composite build. A new settings file establishes plugin-builder as an independent build, the root settings includes it as a composite build rather than a submodule, and build tasks are rewired to reference the included build's JAR artifact instead of subproject paths.

Changes

Cohort / File(s)	Summary
Composite Build Configuration settings.gradle.kts, plugin-api/plugin-builder/settings.gradle.kts	Root settings now includes plugin-builder as a composite build via pluginManagement; plugin-builder removed from standard subproject includes. New settings file for plugin-builder defines rootProject.name and configures dependencyResolutionManagement with google, mavenCentral, and gradlePluginPortal repositories.
Build Task Rewiring app/build.gradle.kts	createPluginArtifactsZip task dependency changed from :plugin-api:plugin-builder:jar (subproject) to gradle.includedBuild("plugin-builder").task(":jar") (composite). JAR source path changed from project layout reference to fixed root path rootProject.file(...).

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Poem

A builder once nested in tree,
Now stands as a build to be free,
Through composites wise, the artifacts rise,
Independence declared—hooray! 🐰✨

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	No pull request description was provided by the author.	Consider adding a brief description explaining the motivation, benefits, and any migration steps involved in moving to composite build.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main change: moving plugin-builder to a composite build architecture.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

plugin-api/plugin-builder/settings.gradle.kts (1)

1-9: Settings configuration is valid.

The composite build setup correctly names the project to match the includeBuild directive in the root settings. The repository configuration covers the essential sources for Gradle plugin development.

Consider adding repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) for consistency with the root project's stricter repository configuration, though this is optional depending on the plugin-builder's needs.

🔎 Optional: Add repositoriesMode for consistency

 rootProject.name = "plugin-builder"

 dependencyResolutionManagement {
+    repositoriesMode.set(RepositoriesMode.PREFER_SETTINGS)
     repositories {
         google()
         mavenCentral()
         gradlePluginPortal()
     }
 }

app/build.gradle.kts (1)

630-641: Hardcoded artifact path should use dynamic resolution like the plugin-api approach.

The task correctly depends on the composite build's :jar task via gradle.includedBuild("plugin-builder").task(":jar"), but the hardcoded path rootProject.file("plugin-api/plugin-builder/build/libs/plugin-builder-1.0.0.jar") is inconsistent with how plugin-api is handled elsewhere in this file. On line 625, the copyPluginApiJarToAssets task uses project(":plugin-api").layout.buildDirectory.file(...) for dynamic resolution, while the createPluginArtifactsZip task hardcodes the path and version.

This creates a maintenance burden: if the plugin-builder version is updated, the hardcoded path on line 635 must also be updated, and this could easily be missed, causing silent failures at runtime.

Consider using a similar dynamic approach (e.g., gradle.includedBuild("plugin-builder").task(":jar").outputs.files) to access the artifact output, making it consistent with the plugin-api pattern and eliminating the hardcoded version dependency.

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9ea4cd4 and f476ed0.

📒 Files selected for processing (3)

• app/build.gradle.kts
• plugin-api/plugin-builder/settings.gradle.kts
• settings.gradle.kts

🔇 Additional comments (1)

settings.gradle.kts (1)

26-28: Composite build inclusion looks correct.

The plugin-builder is appropriately added as an included build within pluginManagement, which is the correct location for builds that provide Gradle plugins or build logic. The naming is consistent with the existing build-logic pattern.