lhotari opened a new pull request, #25435: URL: https://github.com/apache/pulsar/pull/25435
### Motivation Align the Gradle build with [Gradle's documented best practices](https://docs.gradle.org/current/userguide/best_practices_structuring_builds.html) to improve build performance, maintainability, and configuration cache effectiveness. The main issues addressed: 1. **Monolithic `subprojects{}`/`allprojects{}` blocks** — 260+ lines of shared config injected non-obviously, preventing Gradle's Isolated Projects optimization 2. **`buildSrc` instead of composite build** — any change to build logic invalidates the entire build cache ([gradle/gradle#6045](https://github.com/gradle/gradle/issues/6045)) 3. **Conditional module inclusion** — non-deterministic project structure breaks configuration cache and IDE integration 4. **Eager task configuration** — `tasks.withType<>` without `.configureEach` causes unnecessary configuration overhead 5. **Configuration cache invalidation** — `generatePulsarVersion` task's `gitDirty`/`gitCommitId` inputs caused cascading rebuilds across the entire project on every file change ### Modifications **Convention plugins (build-logic composite build replacing buildSrc):** - Created `build-logic/` included build with `pulsar.java-conventions`, `pulsar.code-quality-conventions`, `pulsar.test-certs-conventions`, `pulsar.nar-conventions` convention plugins - Moved existing `pulsar.shadow-conventions` and `pulsar.client-shade-conventions` from `buildSrc` to `build-logic` - Each subproject now explicitly opts in via `plugins { id("pulsar.java-conventions") }` instead of inheriting from `subprojects{}` - Eliminated `afterEvaluate` + reflection for license plugin configuration - Deleted `buildSrc/` and `gradle/code-quality.gradle.kts` **Unconditional module inclusion:** - Removed all 4 conditional blocks from `settings.gradle.kts` (`-PcoreModules`, `-Pdocker`, `-PintegrationTests`, shade-test detection) - All modules are always included; Docker builds only run when explicitly requested - Removed `assemble→dockerBuild` dependency from Docker modules - Made `pulsar-bom` project references unconditional **Configuration cache & build performance:** - All `tasks.withType<>` changed to `tasks.withType<>().configureEach` for lazy task configuration - Removed `gitDirty` and `gitCommitId` from `generatePulsarVersion` task inputs to prevent cascading rebuilds - Migrated `pulsar-functions-runtime-all` fat JAR from manual `dependsOn(runtimeClasspath) + zipTree()` to Shadow plugin for configuration-cache-compatible lazy resolution - Used `shadow { addShadowVariantIntoJavaComponent.set(false) }` in shadow conventions - Disabled microbench shadowJar from assemble lifecycle via `addShadowJarToAssembleLifecycle` **CI & documentation:** - Removed `-PcoreModules` and `-Pdocker` flags from GitHub Actions workflows and `docker/build.sh` - Updated README files to reflect new build commands - Added `version-catalog-update` and `versions` plugins for dependency management ### Verifying this change - [x] Make sure that the change passes the CI checks. This change is already covered by existing tests. Build verification: - `./gradlew help` — configuration phase succeeds - `./gradlew assemble` — full build produces identical artifacts - `./gradlew assemble` (second run) — "Reusing configuration cache", all tasks UP-TO-DATE - `./gradlew clean && ./gradlew assemble` — all `compileJava`/`shadowJar`/`nar` tasks served FROM-CACHE - `./gradlew :pulsar-broker:test --dry-run` — test task graph unchanged - `./gradlew :pulsar-io:pulsar-io-data-generator:nar --dry-run` — NAR packaging works ### Does this pull request potentially affect one of the following parts: - [ ] Dependencies (add or upgrade a dependency) - [ ] The public API - [ ] The schema - [ ] The default values of configurations - [ ] The threading model - [ ] The binary protocol - [ ] The REST endpoints - [ ] The admin CLI options - [ ] The metrics - [ ] Anything that affects deployment ### Documentation - [x] `doc-not-needed` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
