-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Closed
Labels
:Core/Infra/PluginsPlugin API and infrastructurePlugin API and infrastructure>enhancementblockerv2.2.0v5.0.0-alpha1
Description
Things like script engines need to be pulled out into plugins, even if we want to ship them by default with our distribution:
- removes dependences from elasticsearch-core (In case its used e.g. as node client or whatever)
- even pre-bundled, such dependencies are then in isolated classloaders (e.g. some other plugin can use antlr 2.0 or asm 7.0 or whatever and that is fine, since plugins are isolated from each other)
- allows us to better secure things like script engines that do special things.
- plugin mechanism is better than tossing jars around: supports classloader isolation, we already can support unit and integration tests, we can support running these from IDEs, we can support them in our security framework, has additional metadata and compatibility checks, ...
- gives us more possibilities, like allowing users to uninstall stuff, or create "minimal" distribution, OEM packaging, or whatever in the future
I have this as a blocker issue for 3.0 after we do some basic refactoring. It is assigned to me and I will not drop it. However, I would like to delay it for now: If we are going to do a big build refactoring, it might be best to wait for gradle. I don't want to spend days coercing maven poms into doing strange things if there is an easier way.
Metadata
Metadata
Assignees
Labels
:Core/Infra/PluginsPlugin API and infrastructurePlugin API and infrastructure>enhancementblockerv2.2.0v5.0.0-alpha1