[
https://issues.apache.org/jira/browse/KUDU-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188552#comment-17188552
]
Grant Henke commented on KUDU-3188:
-----------------------------------
I don't think shading the dependencies into the Kudu client is done
specifically because of existing compatibility issues or concerns of the
libraries we depend on. Ultimately the goal is to make the Kudu client as
portable and usable in as many projects as possible, including those that use
different (older or newer) version of the libraries that Kudu uses. We shade
these libraries because they are considered internal implementation details, as
opposed to public API, and we would like to maintain the flexibility to change
or remove them without impacting existing users.
It sounds like the primary issue is that the Kudu client is not GraalVM
friendly/compatible. Can you help me to better understand if that is in-fact
the main issue and if we could contribute changes that help alleviate the issue
without "unshading" and effectively adding a new external dependency to the
Kudu client?
> 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
> Priority: Major
>
> 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)
