Building a plugin with Gradle and Elasticsearch 5.0

[nik9000 (Nik Everett)]

@Damien_Alexandre

I read somewhere that since 5.0, plugin authors must release a new version of their plugins every-time Elasticsearch bump a version, is that correct? Even if nothing changes in the plugin?

We check that the version that of Elasticsearch that the plugin was declared to have been built against matches the version you are running it with exactly. This is because plugins get access to all the internal interfaces and classes which we change as needed.

@Damien_Alexandre

My plugin require the latest ICU (58.1) and I have no idea what will happens if an user try to enable both my plugin (ICU 58.1) and the official analysis-icu plugin (ICU 54.1). Maybe I can declare that my plugin should not be enabled alongside analysis-icu? Or will it works ok to have two modules loading their own versions of ICU?

It should work fine. All plugins are loaded in child classloaders.

@Damien_Alexandre

And is it possible to just extend the core analysis-icu plugin? That way my plugin could just add new tokenizer on top of it?

Plugins can't extend plugins at this point. They can't see plugins at all because of the child classloader. We needed this to make plugin security work. You can certainly fork the analysis-icu plugin as a starting point.

@Damien_Alexandre

Is there a magic I didn't see to import this method in the tests?

It is a static method on ESTestCase so it ought to work....

@Damien_Alexandre

I looked at the code, but didn't find a better way to have the default rules + my edits in place

I don't really know ICU so I'm not sure. One advantage that you have is that you tightly control all the versions so while upgrading ICU may break it, no one is going to sneak that in on you.