sjvanrossum opened a new pull request, #39297:
URL: https://github.com/apache/beam/pull/39297
Initially I ran into capability conflicts with #39284 and #39285 because
Kafka 3.9.2 and up depend on at.yawk.lz4:lz4-java.
I figured I'd set up conflict resolution for org.lz4:lz4-java and
at.yawk.lz4:lz4-java at the root, but realized that usage of org.lz4:lz4-java
is undesirable to begin with because it's unmaintained and every version has
known security vulnerabilities.
Capability conflict resolution isn't enough to replace every dependency
(including transitive) on org.lz4:lz4-java, but this can be solved with
dependency substitutions instead (including transitive). Building KafkaIO
(prior to #39284) on its own does not trigger a capability conflict since no
modules providing the org.lz4:lz4-java capability are requested by dependencies
of KafkaIO.
KafkaIO specifies a compileOnly/provided dependency on Kafka client
libraries so the substitution shouldn't propagate in any Beam artifacts, which
means that users of KafkaIO are responsible for substituting `org.lz4:lz4-java`
where/when applicable.
The substitution would be propagated in Beam artifacts with a direct or
transitive implementation dependency on `org.lz4:lz4-java`, meaning that any
dependency on Beam artifacts will transitively include `at.yawk.lz4:lz4-java`
instead.
If the above is considered overly paranoid, then retaining the current
resolution strategy while simplifying maintenance of capability conflict
resolution for org.lz4:lz4-java looks something like this:
```
subprojects {
configurations {
configureEach {
resolutionStrategy {
capabilitiesResolution {
withCapability("org.lz4:lz4-java") {
selectHighestVersion()
}
}
}
}
}
}
```
This would at least unburden contributors and maintainers from patching new
capability conflicts when dependency upgrades replace `org.lz4:lz4-java` as is
the case for #39284.
------------------------
Thank you for your contribution! Follow this checklist to help us
incorporate your contribution quickly and easily:
- [ ] Mention the appropriate issue in your description (for example:
`addresses #123`), if applicable. This will automatically add a link to the
pull request in the issue. If you would like the issue to automatically close
on merging the pull request, comment `fixes #<ISSUE NUMBER>` instead.
- [ ] Update `CHANGES.md` with noteworthy changes.
- [ ] If this contribution is large, please file an Apache [Individual
Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
See the [Contributor Guide](https://beam.apache.org/contribute) for more
tips on [how to make review process
smoother](https://github.com/apache/beam/blob/master/CONTRIBUTING.md#make-the-reviewers-job-easier).
To check the build health, please visit
[https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md](https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md)
GitHub Actions Tests Status (on master branch)
------------------------------------------------------------------------------------------------
[](https://github.com/apache/beam/actions?query=workflow%3A%22Build+python+source+distribution+and+wheels%22+branch%3Amaster+event%3Aschedule)
[](https://github.com/apache/beam/actions?query=workflow%3A%22Python+Tests%22+branch%3Amaster+event%3Aschedule)
[](https://github.com/apache/beam/actions?query=workflow%3A%22Java+Tests%22+branch%3Amaster+event%3Aschedule)
[](https://github.com/apache/beam/actions?query=workflow%3A%22Go+tests%22+branch%3Amaster+event%3Aschedule)
See [CI.md](https://github.com/apache/beam/blob/master/CI.md) for more
information about GitHub Actions CI or the [workflows
README](https://github.com/apache/beam/blob/master/.github/workflows/README.md)
to see a list of phrases to trigger workflows.
--
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]
