Evaluate deprecating Elasticsearch support in next Eclipse JNoSQL version

[otaviojava]

Elasticsearch (ES) support has been available in Eclipse JNoSQL as part of the document database family. However, we should reevaluate its inclusion in the next major version based on recent shifts in the Elasticsearch ecosystem and alignment with developer experience.

Reasons

1. Search-first focus in ES 8.x+
   Recent Elasticsearch releases (particularly those from 8.x onward) have doubled down on their positioning as a search engine, rather than a general-purpose NoSQL document store. This direction increases the gap between ES's capabilities and Jakarta NoSQL's query model.

2. Semantic mismatch
   Jakarta NoSQL defines four NoSQL types: Key-Value, Document, Column, and Graph.
   While Elasticsearch works with JSON documents, it lacks key NoSQL characteristics like:

   • Standard persistence operations
   • Real-time consistency
   • Native CRUD behavior as expected in traditional document databases

3. Complex and evolving DSL

   • Elasticsearch introduces frequent breaking changes in its query DSL.

   • Mapping fluent queries like:

     template.select(Book.class)
             .where("title").contains("Jakarta")
             .or("author").eq("Otavio")
             .result();

     to Elasticsearch's bool query requires non-trivial effort and compromises.

4. Better served by dedicated tools
   Elasticsearch is well-supported by specialized projects like:

   • [Spring Data Elasticsearch](https://spring.io/projects/spring-data-elasticsearch)
   • [Hibernate Search](https://hibernate.org/search/)
   • Native ES SDK (Java High-Level REST Client, now replaced with Elasticsearch Java API Client)

5. Low alignment with Jakarta NoSQL goals
   JNoSQL aims to simplify interactions with NoSQL databases, not full-text indexing/search platforms. Supporting ES adds complexity and ambiguity without strong community demand.