Add support in plugins for a separate spi classloader (#76288) #76364
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SPI is how plugins provide extension points for other plugins to
customize their behavior. Plugins may have a separate SPI jar, so as not
to expose the internals of the plugin implementation. In essense, this
system was built as a stopgap for Java modules, where implementation can
be protected in the same jar. However, currently the plugins service
loads both spi and plugin implementations into the same classloader.
This means that although another plugin may only compile against spi,
they could still get jar hell from a duplicate dependency.
This commit adds support for plugins to contain an "spi" subdirectory
which is loaded into a separate classloader. This spi classloader is a
parent to the plugin implementation, as well as any other plugins which
have extended it. Additionally as a demonstration of how this works in
practice, lang-painless is setup as the first plugin to provide an spi
jar, and sql's dependence on painless is changed to only spi, so that
it now has an independent version of antlr.
closes #74448