I guess I'll just copy them into the artifact server on our side, into the position they used to be at. But this increases the amount of work to do each update.
Yeah. That's what I said previously. You can only use elastic download service for plugins. Some plugins are available on Maven central but they are only the ones which are required by the Java Transport Client.
When the Transport Client will be deprecated (then removed), probably those plugins won't be published anymore.
As a workaround you can use a similar recipe I explained in:
Gotta say I am disappointed by this; this complicates how custom "builds" can be made. We have our own "sbt pipeline" of building services (Elasticsearch being one of them).
In 2.x we could simply create our own "fat JAR" and define the dependencies we needed (e.g. "org.elasticsearch.plugin" % "analysis-icu" % "2.32"). How is this supposed to work, if we were to upgrade to 5.x? There's a good reason why Maven exists, why not utilize it?
We have maany different services, and like to bootstrap and release them right thru the sbt in a similar manner.
This enables us to update our custom Elasticsearch-plugins right thru the sbt, and bundle them in one JAR-file (i.e. the elasticsearch server including custom plugins).
I know this isn't how most users use the server, and I guess most just download the "server ZIP file". But we build most of our services on JVM (Scala), and would like to take advantage of that by including elasticsearch as a Maven-dependency just like everything else.
I used to work on a project that used span queries, which does not analyze
term. To get around this issue, we would recreate the analysis server
locally and analyze the terms. Worked perfectly. Sadly elasticsearch is
becoming less flexible.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.