[jira] [Commented] (KUDU-3188) Consider to stop shading dependencies in kudu-client

["Grant Henke (Jira)" <ji...@apache.org>]

    [ 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)