Peter Palaga created KUDU-3188:
----------------------------------
Summary: Consider to stop shading dependencies in kudu-client
Key: KUDU-3188
URL: https://issues.apache.org/jira/browse/KUDU-3188
Project: Kudu
Issue Type: Improvement
Components: client
Reporter: Peter Palaga
My motivation for asking this is the following:
I work on Apache Camel Quarkus, where we basically port Camel components to
Quarkus incl. native compilation using GraalVM. Java code typically needs to
get prepared for native compilation with GraalVM by registering classes for
reflection, requesting class initialization at runtime, setting class/method
substitutions, etc.
As you may know there is [Kudu Camel
component|https://camel.apache.org/components/latest/kudu-component.html] that
is using kudu-client internally. Porting it to GraalVM is currently quite
cumbersome due to shading.
If Netty was a standard dependency of kudu-client, we could simply re-use the
work done in
[quarkus-netty-extension|https://github.com/quarkusio/quarkus/blob/master/extensions/netty/deployment/src/main/java/io/quarkus/netty/deployment/NettyProcessor.java]
by depending on it in camel-quarkus-kudu. But because netty is shaded in
kudu-client, we have no better choice than copy & adapt all the
quarkus-netty-extension code to Camel Quarkus and maintain it there:
https://github.com/apache/camel-quarkus/pull/1667/files Needless to say, we'd
prefer not maintaining the copied code in Camel Quarkus.
So I'd like to ask whether there is any chance to stop shading Netty and
possibly other kudu-client dependencies.
I wonder which reasons you had for introducing shading originally?
I know that compatibility of Netty between micro releases used to be quite
flaky in the past. The last comment in
https://github.com/netty/netty/issues/7586 brings some hope that it is not an
issue anymore.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
