Plugin dependencies

Elastic Stack Elasticsearch
1

Is there any way to mark a plugin as being dependent upon another plugin?

Sample use case:

Consider the excellent IndexTermlisthttp://jprante.github.com/lessons/2012/03/27/Writing-a-simple-plugin-for-Elasticsearch.htmlsample plugin. The documentation contains a warning that since this plugin
dumps the whole term index into a Set, it's possible that you could
blow out the memory.

I modified this to have it utilize a callback interface such that the terms
are sent back in chunks out of band from the main request. For example, the
caller creates a temp JMS Queue and then invokes the service with the
Queue's address.

I'd prefer to not have the module for the plugin be responsible for
constructing/configuring this callback instance. Instead, I'd like the
callback interface injected into its constructor. If this were possible,
then I could package the callback class into its own plugin. This would be
good from a separation of concerns principle and also simplifies the
testing since I could have my integration tests for the IndexTermlist
plugin stand up a mock callback instance for its assertions.

Thanks in advance.

--

2

Hi

check for "mandatory plugins" at

--Alexander

On Tue, Dec 11, 2012 at 10:46 PM, massfords mark@massfords.com wrote:

Is there any way to mark a plugin as being dependent upon another plugin?

Sample use case:

Consider the excellent IndexTermlisthttp://jprante.github.com/lessons/2012/03/27/Writing-a-simple-plugin-for-Elasticsearch.htmlsample plugin. The documentation contains a warning that since this plugin
dumps the whole term index into a Set, it's possible that you could
blow out the memory.

I modified this to have it utilize a callback interface such that the
terms are sent back in chunks out of band from the main request. For
example, the caller creates a temp JMS Queue and then invokes the service
with the Queue's address.

I'd prefer to not have the module for the plugin be responsible for
constructing/configuring this callback instance. Instead, I'd like the
callback interface injected into its constructor. If this were possible,
then I could package the callback class into its own plugin. This would be
good from a separation of concerns principle and also simplifies the
testing since I could have my integration tests for the IndexTermlist
plugin stand up a mock callback instance for its assertions.

Thanks in advance.

--

--

3

I think "mandatory plugins" is about throwing an exception if a plugin
isn't present at startup but doesn't offer anything with respect to the
order of loading. This helps to avoid the case where a dependency is
missing but doesn't help ensure a dependency contributes its modules to
ES's Injector before they're referenced.

I think configuring my callback service as a "default plugin" though would
work. Those plugins are loaded before the ones discovered on the classpath.

On Tuesday, December 11, 2012 4:48:32 PM UTC-5, Alexander Reelsen wrote:

Hi

check for "mandatory plugins" at
Elasticsearch Platform — Find real-time answers at scale | Elastic

--Alexander

On Tue, Dec 11, 2012 at 10:46 PM, massfords <ma...@massfords.com<javascript:>

wrote:

Is there any way to mark a plugin as being dependent upon another plugin?

Sample use case:

Consider the excellent IndexTermlisthttp://jprante.github.com/lessons/2012/03/27/Writing-a-simple-plugin-for-Elasticsearch.htmlsample plugin. The documentation contains a warning that since this plugin
dumps the whole term index into a Set, it's possible that you could
blow out the memory.

I modified this to have it utilize a callback interface such that the
terms are sent back in chunks out of band from the main request. For
example, the caller creates a temp JMS Queue and then invokes the service
with the Queue's address.

I'd prefer to not have the module for the plugin be responsible for
constructing/configuring this callback instance. Instead, I'd like the
callback interface injected into its constructor. If this were possible,
then I could package the callback class into its own plugin. This would be
good from a separation of concerns principle and also simplifies the
testing since I could have my integration tests for the IndexTermlist
plugin stand up a mock callback instance for its assertions.

Thanks in advance.

--

--

4

I think the idea that a plugin should be able to check other plugins for
existence is quite compelling.

If another plugin is already installed and can be used by other plugin
code, probably by injection, developers could cooperate in their plugin
work. But, instead of forcing the admin to declare plugin presence by a
static mandatory list, I would prefer a dynamic procedure where the node
could detect dependencies between plugins while starting up. Maybe with an
option for automatic plugin installation if a dependency is missing to ease
deployment of complex plugins.

FYI, I have offered a patch for adding the plugin names and their versions
to the node info https://github.com/elasticsearch/elasticsearch/pull/2057
because Ben Birch liked to detect in elasticsearch-head if the skywalker
plugin was there or not. It's just a start for more interesting stuff.

Best regards,

Jörg

--