Hi Ron,
Glad you figured it out! Yes, Drill dependencies are overly complex. One of the
reasons I don't enthusiastically encourage the use of Drill as an emedded query
library is that we don't want to put people through the hassles you are
encountering. Besides Netty, Guava is an ongoing source of pain, even within
Drill itself.
If there is interest in using Drill in embedded mode inside other apps, then
someone should figure out how we a) run Drill in a dedicated class loader, and
b) load plugins in their own class loaders. Java 9 was supposed to provide
mechanisms to help with this, but I think there are limits.
There is also the challenge that the JDBC driver itself includes a large amount
of Drill's dependencies (to run the RPC mechanism work with vectors, etc.) We
should a) simplify the client, or b) load Drill's "guts" in a separate class
loader, as in the above scenario.
Anyone looking for a challenging Drill project; this is a good candidate.
Sounds like you know the Maven tricks: use dependency tree to figure out who is
including what, then try to whack the problems one by one with dependency
management. (That is one of the most painful parts of Maven IMHO.)
Thanks,
- Paul
On Thursday, February 6, 2020, 8:27:31 PM PST, Ron Cecchini
<[email protected]> wrote:
Quick apology for asking a boneheaded question... esp. when the answer was
actually staring me in the face.
Apparently I just kept messing up the Maven exclusions on the 'drill-jdbc-all'
dependency...
FWIW, I had to exclude both the 4.0.48 'netty-handler' and 'netty-common' from
'drill-jdbc-all' to allow the Kotlin stuff to pull in the newer 4.1.24 versions
of the netty libraries. (using Maven's <dependencyManagement> to encorce
4.1.24 also worked.)
> On February 5, 2020 at 6:28 PM Ron Cecchini <[email protected]> wrote:
>
>
> TL;DR: my Maven Fu is failing and I'm encountering a bad transitive
> dependency...
