Remove unused Spring Boot plugin from kafkaschemaregistry#11406
Conversation
Adds a new included build `build-logic/` hosting a single subproject
`smoke-test` that exposes the `dd-trace-java.smoke-test-app` plugin.
The plugin contributes:
- `NestedGradleBuild` task type that runs a nested Gradle build via the
Gradle Tooling API. It pins the nested Gradle version (no committed
per-application wrappers), uses the configured Java toolchain for the
nested daemon, forwards artifact paths from the root build as
`-P<name>=<path>`, and redirects the nested `buildDir` via
`-PappBuildDir=<path>` so outputs land under the outer project's build
directory.
- `smokeTestApp` project extension with an `application { ... }` block
that registers the `NestedGradleBuild` task, wires it into every `Test`
task via `dependsOn` + a `jvmArgumentProvider` for the produced
artifact's system property. Consumers can also register
`NestedGradleBuild` directly when they need more control; the plugin
is a no-op until `application` or a manual registration is done.
- `projectJar(name, project)` helper that forwards a sibling project's
jar to the nested build through a resolvable `Configuration` (avoids
`evaluationDependsOn` and the cross-project access ordering issues).
The plugin is verified with JUnit 5 unit tests (`ProjectBuilder`) and
end-to-end tests that drive the Tooling API path through the Gradle Test
Kit with a temporary Kotlin-DSL test project.
`build-logic/settings.gradle.kts` references the existing
`gradle/libs.versions.toml` catalog (mirroring `buildSrc/`) so the
plugin can use the same library coordinates as the rest of the repo.
The Gradle libs Maven repository (`https://repo.gradle.org/gradle/libs-releases`,
scoped to `org.gradle:`) is added to the root build's `pluginManagement`
and to `gradle/repositories.gradle` so the Tooling API jar resolves.
Smoke-test modules with Spring Boot plugin versions incompatible with
Gradle 9 will use this plugin in follow-up PRs instead of a committed
Gradle 8 wrapper.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…14.5
Set conventions on `smokeTestApp`:
- `gradleVersion` defaults to `"8.14.5"` (Gradle 8 last release; pinned because
Spring Boot plugin pre-3.5 calls `Configuration.getUploadTaskName()`, removed
in Gradle 9).
- `javaLauncher` defaults to a JDK 21 toolchain (the version the root build
requires for its own Gradle 9 migration; standardising the nested daemon on
the same JDK avoids requiring an extra toolchain on dev machines and CI
runners).
Consumers that need a different JDK or Gradle version still override
explicitly. The inner build script is responsible for pinning the produced
bytecode level (`java { sourceCompatibility = JavaVersion.VERSION_1_8 }` or
similar) — Gradle adds `--release N` automatically when source/target differs
from the daemon JVM.
`JavaToolchainService` is now injected into the extension; this works in any
project where a `java*` (or related) plugin is applied. Smoke-test modules
already apply `gradle/java.gradle`, which applies `java`, so the convention
resolves on first read.
Public defaults exposed as `DEFAULT_NESTED_GRADLE_VERSION` and
`DEFAULT_NESTED_JAVA_VERSION` constants so the values are discoverable.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
e55336a to
e156ee4
Compare
This comment has been minimized.
This comment has been minimized.
…ugin
Switch the plugin sources and unit tests over to the typed
`org.gradle.kotlin.dsl` extension functions where they replace
`::class.java` boilerplate:
- `tasks.register(name, Type::class.java) { … }` → `tasks.register<Type>(name) { … }`
- `tasks.withType(Type::class.java).configureEach { … }` → `tasks.withType<Type>().configureEach { … }`
- `extensions.create("name", Type::class.java)` → `extensions.create<Type>("name")`
- `extensions.getByType(Type::class.java)` → `extensions.getByType<Type>()`
- `extensions.findByName("name")` (followed by `isInstanceOf`) → `extensions.findByType<Type>()`
- `project.plugins.apply(Plugin::class.java)` → `project.apply<Plugin>()` (PluginAware)
- `objects.newInstance(Type::class.java)` → `objects.newInstance<Type>()`
Also drop the six `captured*` local variables in `SmokeTestAppExtension.application` —
inside `tasks.register<NestedGradleBuild>(taskName) { … }` the outer extension's
properties are now reached via `this@SmokeTestAppExtension.<prop>` directly.
No behavioural change; the 9 plugin tests still pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…registry The Spring Boot Gradle plugin was applied but the module never produced a bootJar/bootWar — it ships a shadow jar instead. Removing the plugin eliminates a Gradle-9 blocker (the plugin's pre-3.5.0 versions call `Configuration.getUploadTaskName()`, removed in Gradle 9) with no behavioural change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
e156ee4 to
d620337
Compare
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
error while getting head build completion result DetailsError: There was an error while retrieving the result for pipeline 114148778 FullStacktrace: |
What Does This Do
Removes
id 'org.springframework.boot'(version 2.6.3) and the matchingapply from: "$rootDir/gradle/spring-boot-plugin.gradle"line fromdd-smoke-tests/datastreams/kafkaschemaregistry/build.gradle. The module's actual artifact is ashadowJar; the Spring Boot plugin was applied but never used.Motivation
The Spring Boot Gradle plugin pre-3.5.0 calls
Configuration.getUploadTaskName(), removed in Gradle 9. This module is one of the smoke tests blocking the root Gradle 9 migration. Since the plugin is unused, removing it eliminates the blocker with no behavioural change —shadowJarstill produces the same artifact.Additional Notes
Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labels🤖 Generated with Claude Code