Major Description
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 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 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.
Attachments
Issue Links
- links to