yuqi1129 opened a new issue, #11480:
URL: https://github.com/apache/gravitino/issues/11480
### What would you like to be improved?
`distribution/package/libs/` contains two versions of `slf4j-api`
simultaneously:
```
slf4j-api-2.0.16.jar
slf4j-api-2.0.17.jar
```
**Root cause**: the version catalog pins `slf4j = "2.0.16"`, but
`log4j-slf4j2-impl:2.25.4` (included in the `bundles.log4j` bundle used by
`core`, `server`, and `server-common`) declares a transitive dependency on
`slf4j-api:2.0.17`.
The root `assembleDistribution` task collects `runtimeClasspath` from each
subproject independently. Modules that include `bundles.log4j` resolve
`slf4j-api` to `2.0.17` via conflict resolution; modules without it resolve to
the catalog-pinned `2.0.16`. Both end up in the same output directory because
they have different filenames, bypassing `DuplicatesStrategy.EXCLUDE`.
Affected paths (verified on current `main`):
- `distribution/package/libs/`
- `distribution/package-all/libs/`
### How should we improve?
Fix the inconsistency so all modules resolve `slf4j-api` to a single
version. Possible approaches:
1. **Bump the version catalog** entry `slf4j = "2.0.16"` → `"2.0.17"` to
align with what `log4j-slf4j2-impl:2.25.4` already requires (cleanest).
2. **Add a global constraint**
`resolutionStrategy.force("org.slf4j:slf4j-api:2.0.17")` in the root build so
all subprojects converge at resolution time.
3. **Exclude the old jar** in the copy task with
`exclude("slf4j-api-2.0.16.jar")` (fragile — version-hardcoded, not
recommended).
Option 1 or 2 addresses the root cause.
--
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]
