XComp commented on code in PR #677:
URL:
https://github.com/apache/flink-kubernetes-operator/pull/677#discussion_r1354589163
##########
flink-autoscaler/pom.xml:
##########
@@ -45,6 +45,32 @@ under the License.
<scope>provided</scope>
</dependency>
+ <dependency>
+ <groupId>org.projectlombok</groupId>
+ <artifactId>lombok</artifactId>
+ <version>${lombok.version}</version>
+ <scope>provided</scope>
+ </dependency>
+
+ <dependency>
+ <groupId>org.junit.jupiter</groupId>
+ <artifactId>junit-jupiter-params</artifactId>
+ <scope>test</scope>
+ </dependency>
+
+ <!-- TODO FLINK-33098: These jackson dependencies can be replaced with
flink shaded jackson. It can be done
Review Comment:
hm, thinking about it: Doesn't we add an extra layer of complexity here?
Let's say that there's a CVS in the dependency which requires us to update the
version. Relying on Flink's shaded dependency would mean that we would have to
wait for `flink-shaded` to be updated.
Taking one step back - isn't the question: Do we need to shade the jackson
dependency?
If the answer is yes, shouldn't the Kubernetes Operator shade its dependency
to be independent of `flink-shaded` releases and be able to react faster when
having to update those dependencies?
If the answer is no, we could just use the dependency as is and don't need
to worry about excluding anything from Flink (because its dependency is shaded
already).
Its the same approach how we want to deal with it for external connectors as
far as I understand. And if I understand the motivation correctly, shading
should be necessary so that downstream projects (i.e. custom auto-scaler
implementations) would be able to handle their own dependency versions. Does
that make sense?
--
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]
