bobbai00 opened a new issue, #4554:
URL: https://github.com/apache/texera/issues/4554
## Summary
`LICENSE-binary` lists two versions of the same library:
```
org.reactivestreams.reactive-streams-1.0.3.jar
org.reactivestreams.reactive-streams-1.0.4.jar
```
Both jars are actually shipped — different subprojects resolve to different
versions.
## Where each version is used
| Subproject | Version on runtime classpath |
|---|---|
| `amber`, `computing-unit-managing-service`, `file-service`,
`workflow-compiling-service` | `1.0.4` |
| `access-control-service`, `config-service` | `1.0.3` |
## Root cause (verified via `sbt dependencyTree`)
`reactive-streams` is **purely transitive** — no `build.sbt` declares it
directly.
For the two services pinned to `1.0.3`, the chain is:
```
access-control-service / config-service
└─ org.jooq:jooq:3.16.23 (direct dep)
└─ io.r2dbc:r2dbc-spi:0.9.0.RELEASE
└─ org.reactivestreams:reactive-streams:1.0.3 ← pinned here
```
For everything else, AWS SDK 2.29.51, Apache Pekko 1.2.1, RxJava 3.1.6, and
others all request `1.0.4`, and Coursier picks the highest.
## Suggested fix
Add a `dependencyOverrides` entry in the two affected subprojects to force
`1.0.4`:
```scala
// access-control-service/build.sbt and config-service/build.sbt
dependencyOverrides += "org.reactivestreams" % "reactive-streams" % "1.0.4"
```
After that, only `reactive-streams-1.0.4.jar` will ship and the `1.0.3` line
can be removed from `LICENSE-binary`.
## Why it matters
- Smaller, less confusing binary distribution.
- Fewer entries to keep correct in `LICENSE-binary`.
- `1.0.3` and `1.0.4` are wire-compatible (same `org.reactivestreams.*`
API), so the override is safe.
## Notes
- Both versions are MIT-licensed (CC0 in some redistributions); current
`LICENSE-binary` placement is correct either way.
- This was discovered while reviewing `LICENSE-binary` for the binary
release.
--
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]
