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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
