[ANN] Extended analyze plugin

Elastic Stack Elasticsearch
1

Hi all,

I'm developing extended _analyze plugin. Such as a solr's analysis page.

I have few question plugin development.

  1. Is this name easy to understand ?

  2. I create pom.xml based on elasticsearch-analysis-kuromoji’s pom.xml. I use org.elasticsearch to and package.
    Should I change it like info.johtani…?

I am a beginner of elasticsearch plugin development.
Give me some advice, please.

Regards

Jun Ohtani
johtani@gmail.com
blog : http://blog.johtani.info
twitter : http://twitter.com/johtani

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

2

  1. Yes, why not?

  2. For maven group management, it is preferable to use an own group ID. So
    you can distribute your code seamless over the many repos out there, being
    the maintainer of the group. More, using an own package in Java, the ES
    core team can't get confused about code in stacktraces when it comes to bug
    hunting while doing customer support. Also, for plugin zip assembly, it is
    convenient to manage an own java package name for include/exclude filtering
    code jars.

I recommend to provide binaries for easy install.

Cheers and happy plugin hacking

Jörg

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

3

Hi Jörg,

Thanks for quick reply and advice!

I will change own java package name.
And provide binaries.

Jun Ohtani
johtani@gmail.com
blog : http://blog.johtani.info
twitter : http://twitter.com/johtani

2013/10/31 23:09、joergprante@gmail.com のメール：

  1. Yes, why not?

  2. For maven group management, it is preferable to use an own group ID. So you can distribute your code seamless over the many repos out there, being the maintainer of the group. More, using an own package in Java, the ES core team can't get confused about code in stacktraces when it comes to bug hunting while doing customer support. Also, for plugin zip assembly, it is convenient to manage an own java package name for include/exclude filtering code jars.

I recommend to provide binaries for easy install.

Cheers and happy plugin hacking

Jörg

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.