# Plugin dependencies **URL:** \ **Category:** Elasticsearch\ **Created:** [December 11, 2012, 9:46pm UTC](https://discuss.elastic.co/t/plugin-dependencies/10047 "2012-12-11T21:46:01Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![massfords](https://avatars.discourse-cdn.com/v4/letter/m/e47c2d/32.png) [@massfords](https://discuss.elastic.co/u/massfords)\ **Post date:** [December 11, 2012, 9:46pm UTC](https://discuss.elastic.co/t/plugin-dependencies/10047/1 "2012-12-11T21:46:01Z")
Is there any way to mark a plugin as being dependent upon another plugin? _Sample use case:_ Consider the excellent IndexTermlist[http://jprante.github.com/lessons/2012/03/27/Writing-a-simple-plugin-for-Elasticsearch.html](http://jprante.github.com/lessons/2012/03/27/Writing-a-simple-plugin-for-Elasticsearch.html)sample 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. -- ---
**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\ **Post date:** [December 11, 2012, 9:48pm UTC](https://discuss.elastic.co/t/plugin-dependencies/10047/2 "2012-12-11T21:48:32Z")
Hi check for "mandatory plugins" at > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. --Alexander On Tue, Dec 11, 2012 at 10:46 PM, massfords [mark@massfords.com](mailto:mark@massfords.com) wrote: > Is there any way to mark a plugin as being dependent upon another plugin? > > _Sample use case:_ > > Consider the excellent IndexTermlist[http://jprante.github.com/lessons/2012/03/27/Writing-a-simple-plugin-for-Elasticsearch.html](http://jprante.github.com/lessons/2012/03/27/Writing-a-simple-plugin-for-Elasticsearch.html)sample 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. > > -- -- ---
**Author:** ![massfords](https://avatars.discourse-cdn.com/v4/letter/m/e47c2d/32.png) [@massfords](https://discuss.elastic.co/u/massfords)\ **Post date:** [December 11, 2012, 10:02pm UTC](https://discuss.elastic.co/t/plugin-dependencies/10047/3 "2012-12-11T22:02:55Z")
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](http://www.elasticsearch.org/guide/reference/modules/plugins.html) > > --Alexander > > On Tue, Dec 11, 2012 at 10:46 PM, massfords \<[ma...@massfords.com](mailto:ma...@massfords.com)\ > > > wrote: > > > Is there any way to mark a plugin as being dependent upon another plugin? > > > > _Sample use case:_ > > > > Consider the excellent IndexTermlist[http://jprante.github.com/lessons/2012/03/27/Writing-a-simple-plugin-for-Elasticsearch.html](http://jprante.github.com/lessons/2012/03/27/Writing-a-simple-plugin-for-Elasticsearch.html)sample 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. > > > > -- -- ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [December 11, 2012, 10:36pm UTC](https://discuss.elastic.co/t/plugin-dependencies/10047/4 "2012-12-11T22:36:57Z")
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](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 -- ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:00am UTC](https://discuss.elastic.co/t/plugin-dependencies/10047/5 "2017-07-06T03:00:13Z")