Fix dependencies of the plugin-bundle module#70
Conversation
There was a problem hiding this comment.
Pull request overview
This PR enables the CoreJvm Gradle Plugin to work independently without requiring the Compiler Gradle Plugin to be explicitly added to the build classpath. The changes make the plugin-bundle self-contained by including all necessary compiler dependencies as runtime dependencies in the published POM, while removing the requirement for users to manually add these dependencies.
Changes:
- Bumped version from 2.0.0-SNAPSHOT.051 to 2.0.0-SNAPSHOT.052
- Extended
plugin-bundleto add compiler dependencies (compiler-gradle-plugin, compiler-gradle-api, compiler-params, protobuf-java-util) to the published POM with appropriate exclusions - Removed explicit Compiler plugin classpath dependencies from
tests/build.gradle.ktssince they're now provided transitively - Changed plugin application from string ID to type-safe class references in CoreJvmPlugin and CompilerConfigPlugin
- Added
gradleKotlinDsl()compileOnly dependency to support Kotlin DSL extension functions
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| version.gradle.kts | Version bump to 2.0.0-SNAPSHOT.052 |
| pom.xml | Version bump to match new snapshot version |
| plugin-bundle/build.gradle.kts | Added compiler dependencies (compiler-gradle-plugin, compiler-gradle-api, compiler-params, protobuf-java-util) to POM manipulation with exclusions; minor grammar fix in comment |
| tests/build.gradle.kts | Removed explicit Compiler plugin classpath dependencies that are now provided transitively |
| gradle-plugins/src/main/kotlin/io/spine/tools/core/jvm/gradle/plugins/CoreJvmPlugin.kt | Changed to apply ProtobufPlugin by class instead of by ID; renamed helper method from apply to doApply for clarity |
| gradle-plugins/src/main/kotlin/io/spine/tools/core/jvm/gradle/plugins/CompilerConfigPlugin.kt | Changed to apply CompilerGradlePlugin by class; removed unused imports |
| gradle-plugins/build.gradle.kts | Added gradleKotlinDsl() as compileOnly dependency for Kotlin DSL extensions |
| dependencies.md | Auto-generated dependency report with updated timestamps and version references |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
plugin-bundleplugin-bundle module
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| private fun Project.applyProtobufPlugin() { | ||
| if (!pluginManager.hasPlugin(ProtobufGradlePlugin.id)) { | ||
| // We carry the plugin as a runtime dependency of the fat JAR. | ||
| // So it will be available in the build classpath and found by the ID. | ||
| pluginManager.apply(ProtobufGradlePlugin.id) | ||
| project.apply<ProtobufPlugin>() | ||
| } |
There was a problem hiding this comment.
applyProtobufPlugin() applies Protobuf by class (apply<ProtobufPlugin>()) but the surrounding logic still relies on plugin ID checks/callbacks (hasPlugin(ProtobufGradlePlugin.id) here, and withPlugin(ProtobufGradlePlugin.id) in apply). When a plugin is applied by type, Gradle does not reliably associate it with an ID, so the ID-based check/callback may not observe the plugin and applyCoreJvmPlugins() may never run when Protobuf wasn’t already applied by ID. Prefer class-based checks/hooks (e.g., plugins.hasPlugin(ProtobufPlugin::class.java) / plugins.withType(ProtobufPlugin::class.java)) or apply CoreJvm plugins immediately after applying Protobuf.
| * Add the dependency on the Protobuf Java Util library because it is | ||
| * used from the `compiler-params` module. Since we exclude the dependencies | ||
| * on Protobuf, we need to add the Util library manually. | ||
| * The code in `pom.xml` would look like this: |
There was a problem hiding this comment.
There’s an extra leading space in the block comment line before “The code in pom.xml would look like this:”, which makes the comment formatting inconsistent with the surrounding KDoc-style blocks. Consider removing the extra space for consistent formatting.
| * The code in `pom.xml` would look like this: | |
| * The code in `pom.xml` would look like this: |
This PR extends the code of manipulation with
pom.xmlin theplugin-bunlemodule so that CoreJvm Gradle Plugin can work by its own without requiring Compiler Gradle Plugin being already in the build classpath.The
tests/build.gradle.ktswas adjusted accordingly.Other notable changes