Abacn commented on code in PR #39297:
URL: https://github.com/apache/beam/pull/39297#discussion_r3571794675
##########
build.gradle.kts:
##########
@@ -1056,3 +1056,22 @@ if (project.hasProperty("testJavaVersion")) {
}
}
}
+
+subprojects {
Review Comment:
The consideration I made capability resolution opt-in, instead of the
default, in #39061 was to make sure we don't introduce new capability conflict
in other Beam modules unintentionally. Because Gradle's
`resolutionStrategy.capabilitiesResolution.withCapability` closure isn't
transitive. i.e., downstream module compilation still need the same override.
This was exactly what happens to beam-runners-flink-2.1 (after Flink 2.1
override "org.lz4:lz4-java" -> "at.yawk.lz4:lz4-java") and beam-examples-java
(after Beam Flink runner override "org.lz4:lz4-java" -> "at.yawk.lz4:lz4-java")
Flink runner related components currently have this conflict due to Flink
2.1+ and Kafka 2.4 each have transitive dependency on 'org.lz4:lz4-java'
capability from different packages
The bottom line is we don't propagate this conflict to user if they use a
critical setup (Beam core + GCP dependencies + Dataflow runner)
I recommend we remain the opt-in mechism (use resolveCapabilitiesConflict in
individual module), and if ever it propagates to (Beam core + GCP dependencies
+ Dataflow runner), we then need to bump their transitive dependency version to
make sure there isn't capability conflict in the first place
It's fine to bump Beam's Kafka version requirement to 3.9.2, if it
eliminates the capability conflict
--
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]
