# What's the concept of making plugins

**URL:** <https://discuss.elastic.co/t/whats-the-concept-of-making-plugins/68318>\
**Category:** Elasticsearch\
**Created:** [December 7, 2016, 3:29pm UTC](https://discuss.elastic.co/t/whats-the-concept-of-making-plugins/68318 "2016-12-07T15:29:33Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![JonathanAaron](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jonathanaaron/32/24405_2.png) [@JonathanAaron](https://discuss.elastic.co/u/JonathanAaron)\
**Post date:** [December 7, 2016, 3:29pm UTC](https://discuss.elastic.co/t/whats-the-concept-of-making-plugins/68318/1 "2016-12-07T15:29:34Z")

</div>

I'm new to developing elasticsearch plugins. I'm not sure what the concept is for the plugins. Are you essentially overwriting Elasticsearch objects and adding them to the classpath?

Thanks!

---

<div class="post-metadata">

**Author:** ![nik9000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nik9000/32/44947_2.png) [@nik9000](https://discuss.elastic.co/u/nik9000)\
**Post date:** [December 8, 2016, 2:04pm UTC](https://discuss.elastic.co/t/whats-the-concept-of-making-plugins/68318/2 "2016-12-08T14:04:58Z")

</div>

Yes, it amounts to writing Java code that is on the classpath. Technically each plugin is loaded in a child classloader so each plugin can load different versions of the same jar and still work. The cost of this is that plugins can't communicate with each other. I mean, we could write a system that'd let them communicate in a round about way but we haven't seen the need to do that and so we haven't.

To get the plugin loaded you need to make a [few files](https://www.elastic.co/guide/en/elasticsearch/plugins/master/plugin-authors.html) in a zip file. You can make them yourself and put them where they need to be or you can use our [build plugin](http://search.maven.org/#artifactdetails%7Corg.elasticsearch.gradle%7Cbuild-tools%7C5.0.2%7Cjar) which you apply like this: `apply plugin: 'elasticsearch.esplugin'`. I'm not 100% sure how you make sure gradle pulls it in.

The other funky thing about writing Elasticsearch plugins is that Elasticsearch runs in a relatively secured setup. It runs with the JVM's security turned on which means that plugins that need permissions that Elasticsearch doesn't grant itself need jump through a few hoops. One of the links above describes how you check for a permission. [This](https://github.com/elastic/elasticsearch/tree/master/modules/lang-painless/src/main/plugin-metadata) is an example of a plugin that declares the extra permissions that it needs.

Finally, you actually stick your classes at the extension points by extending `org.elasticsearch.plugins.Plugin` and implementing one or more of the interfaces [here](https://github.com/elastic/elasticsearch/blob/master/core/src/main/java/org/elasticsearch/plugins/Plugin.java#L60-L69). That really is the end of the "formal" plugin API. Beyond that all the APIs are internal and subject to change on every release.

---

<div class="post-metadata">

**Author:** ![JonathanAaron](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jonathanaaron/32/24405_2.png) [@JonathanAaron](https://discuss.elastic.co/u/JonathanAaron)\
**Post date:** [December 8, 2016, 8:47pm UTC](https://discuss.elastic.co/t/whats-the-concept-of-making-plugins/68318/3 "2016-12-08T20:47:08Z")

</div>

Thanks Nik! I've been thinking about making a plugin, but wasn't sure of how it all worked.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [January 5, 2017, 8:47pm UTC](https://discuss.elastic.co/t/whats-the-concept-of-making-plugins/68318/4 "2017-01-05T20:47:10Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
