You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by "lhotari (via GitHub)" <gi...@apache.org> on 2026/06/13 04:09:15 UTC

[PR] [improve][build] Correct api/implementation dependency scopes and drop blanket POM exclusions [pulsar]

lhotari opened a new pull request, #26020:
URL: https://github.com/apache/pulsar/pull/26020

   > [\!IMPORTANT]
   > This PR builds on **#26018** and includes its commit (making the public v5 client libraries publishable). **#26018 should be merged before this PR.** Once #26018 is merged into `master`, this PR's diff reduces to just the dependency-classification and exclusion-cleanup commit.
   
   ### Motivation
   
   The published Pulsar POMs have two dependency-metadata problems:
   
   1. **Wrong dependency scopes (`runtime` instead of `compile`).** Many modules declare dependencies as `implementation` even when those dependencies' types appear in the module's public API. Gradle maps `implementation` to `<scope>runtime</scope>` in the published POM (and to the runtime-only variant in Gradle Module Metadata), so consumers cannot compile against types the API exposes. For example, `pulsar-client-original` exposes `pulsar-common`, `opentelemetry-api`, `guava`, `async-http-client`, `slog`, `avro` and `jspecify` types through its API, but published them all as `runtime`.
   
   2. **Blanket `<exclusion>` entries on every dependency.** `pulsar.java-conventions` used `configurations.all { exclude(...) }` to drop `log4j-slf4j-impl` and `bc-fips`. Per-configuration excludes are written onto *every* dependency of *every* published POM, so each dependency carried two spurious `<exclusion>` blocks (e.g. `pulsar-client-original`'s POM had 56 exclusions).
   
   ### Modifications
   
   **api vs implementation classification** (ABI-driven, via the dependency-analysis Gradle plugin's `buildHealth`):
   
   - Promote 153 dependency declarations across 34 modules from `implementation` to `api` where the dependency's types are part of the module's public API; genuinely internal dependencies stay `implementation`. Published POMs now carry the correct `compile`/`runtime` scopes and the matching Gradle Module Metadata variants.
   
   **Remove blanket POM exclusions:**
   
   - Both `log4j-slf4j-impl` (SLF4J 1.x bridge, conflicts with Pulsar's SLF4J 2.x) and `bc-fips` (conflicts with `bcprov-jdk18on`) only arrive transitively through `bookkeeper-server`, which already has a component-metadata rule stripping its BouncyCastle. Extend that rule to also drop `log4j-slf4j-impl`, and remove the two `configurations.all { exclude(...) }` blocks plus the module-name-based `modulesUsingBcFips` allowlist. The FIPS modules declare `bc-fips` directly, so they are unaffected.
   
   **Included from #26018** (first commit): v5 client modules use `pulsar.public-java-library-conventions`, a `mavenPublishLock` shared build service serializes uploads, and a CI step runs `publishAllPublicationsToLocalDeployRepository`.
   
   ### Verifying this change
   
   - [x] Make sure that the change passes the CI checks.
   
   This change is build/release configuration, verified locally as follows:
   
   - `./gradlew compileJava compileTestJava` passes (the `implementation→api` promotions are additive and cannot break consumers; the exclusion change introduces no classpath conflicts).
   - `./gradlew spotlessCheck checkstyleMain checkstyleTest` passes.
   - `./gradlew publishAllPublicationsToLocalDeployRepository` succeeds; the generated POMs no longer contain any `log4j-slf4j-impl`/`bc-fips` exclusions (e.g. `pulsar-client-original`: 56 → 4 exclusions, only the legitimate per-dependency ones) and carry correct dependency scopes.
   - `dependencyInsight` confirms `bc-fips` remains on the FIPS modules' classpaths (e.g. `pulsar-common` test, `bouncy-castle/bcfips`) and is absent from non-FIPS runtime classpaths, and that `log4j-slf4j-impl` is absent.
   
   ### Does this pull request potentially affect one of the following parts:
   
   *If the box was checked, please highlight the changes*
   
   - [x] Dependencies (add or upgrade a dependency): no dependencies are added or upgraded, but the **dependency scopes** in published POMs change (many `implementation`/`runtime` dependencies become `api`/`compile`), and the spurious `log4j-slf4j-impl`/`bc-fips` `<exclusion>` entries are removed from every published POM.
   - [ ] 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
   - [x] Anything that affects deployment: the `pulsar-client-api-v5` and `pulsar-client-v5` artifacts are now published (from #26018), and the dependency scopes of published artifacts change as described above.
   


-- 
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: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [improve][build] Fix publishing of public libraries with correct POM and Gradle module metadata [pulsar]

Posted by "merlimat (via GitHub)" <gi...@apache.org>.
merlimat merged PR #26020:
URL: https://github.com/apache/pulsar/pull/26020


-- 
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: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org