Ok, I surrender.
so it's going to be `org.hibernate.search.backend.elasticsearch`. Even
if it's not ideal in the context of Hibernate Search 5.x, IMO long
term stability is more important for people.
For the record I still think this tendency to over-qualify things and
add many prefixes should be put under control. I totally understand it
makes sense to "us" but please make an effort to look at how people
use things: for users this is just "the ES stuff", but whatever they
won't care about the prefix anyway :)
Remember this though: when you'll want to include include more than
just the backend bits in this module you will have resistance against
changing the name.
Thanks,
Sanne
On 3 May 2018 at 13:26, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
On Thu, May 3, 2018 at 2:17 PM, Yoann Rodiere
<yoann(a)hibernate.org> wrote:
>
> Still, there are several reasons because of which I'd rather use
> "org.hibernate.search.backend.<elasticsearch/lucene>":
>
> It is closer to how we will probably refer to the module on a day-to-day
> basis: I don't know about you, but I'll probably talk about "the
> Elasticsearch backend" rather than "Elasticsearch indexing" or
"the
> Elasticsearch module".
So, you might remember that I was the one proposing "indexing.elasticsearch"
and this is the main argument that convinced me.
>
> It is consistent with our architecture and APIs in Search 6:
>
> The main component (and entry point) in those modules will be an object
> implementing BackendImplementor (SPI)
> We will actually expose "backends" as part of our Java APIs, for instance
> to allow users to retrieve the Elasticsearch client, or to query some
> backend-scoped metadata.
> We will also use the word "backend" in the user configuration, where the
> user will have to define a backend, its type and its options using the
> "hibernate.search.backends.<backendName>.*" properties
+ this one.
We can use whatever name we want for Search 5 but I think the "backend"
choice is pretty obvious for Search 6.
--
Guillaume