paul-rogers opened a new pull request #2074: URL: https://github.com/apache/drill/pull/2074
# [DRILL-7728](https://issues.apache.org/jira/browse/DRILL-7728): SPI framework ## Description We have discussed moving Drill to a "Service Provider Interface" (SPI) model similar to what Presto uses, and modelled after the Java [ServiceLoader](https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html) concept. There are several parts. This PR is for the core mechanism explained [here](https://github.com/paul-rogers/drill/blob/03b36378c6380e6cda76328f5d77bb1d298fe65d/common/src/main/java/org/apache/drill/extn/README.md) to host extensions in Drill. The layout seems the simplest possible way to handle complex plugins; comments and suggestions welcome. In particular, is there some existing model we can adopt? I didn't find any and the Java `ServiceLoader` is just a bit *too* simple. The eventual goal is to provide class loader isolation so that an extension can use one version of Guava, say, and Drill another. This PR implements a lesser form: classes from one extension will not clash with those from another. However, it uses the default class lookup: Drill's own classes are resolved first, then the extension's classes. This interim solution works fine except when we have a conflict. We can add the stricter form later. Some effort went into ensuring this approach will work with Java 9 (and later) modules, but have not done extensive testing. Once the core mechanism is available, the next step is to define the SPI interfaces for things like UDFs, storage plugins and format plugins. ## Documentation The file linked above will eventually be the basis for user documentation for how to build and install extensions using SPI. ## Testing Added unit tests. Doing so required the use of test jar files. After much gnashing of teeth, was able to get Maven to build them and *not* install them in the local repo. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
