Hello,

Thanks for your report. From what I understand, you want to write an application where you define some configuration for the Hibernate Search Elasticsearch integration, but do not always use it at runtime. I suppose you deploy you application in multiple different ways, and in some deployments you don't need the in all deployments.
Because the annotation configuration has to be in the "core" module of your application, with the entities, you would like the configuration to require as little dependencies as possible.
If that's not the case, well, I guessed wrong, and I'll need more information.

First, let's make it clear that the annotation configuration is bound to disappear. In Hibernate Search 6 (still in development), you don't have it anymore, and instead rely on some programmatic API to register the analyzer definitions. A similar API is available in Search 5.

Second, there are already ways for you to avoid the dependencies when you don't need them:

1. You could simply exclude the REST dependencies you don't like using Maven's dependency exclusion feature, or a similar feature in your build tool (I'm sure Gradle provides something similar). As long as you don't start an Elasticsearch index, it should work just fine.
2. Or you could make the modular and multi-deployment nature of your application more explicit: have a separate myapplication-elasticsearch module that provides a ElasticsearchAnalysisDefinitionProvider implementation, and when assembling a "deployment", just make sure to include that module of yours and to set the appropriate properties in your configuration (hibernate.search.elasticsearch.analysis_definition_provider in particular).

I would argue that the second solution would be more future-proof, as you could also remove even more code when you don't need the Elasticsearch integration (you wouldn't even have to include the Hibernate-search-elasticsearch JAR), as long as the only thing you depend on is the Elasticsearch analyzers.

Now, we could, indeed, separate our APIs from our implementation, have one module for each. We (the dev team) discussed that recently and decided against it, mainly because it turned out not to make our main goal (using a more permissive license for APIs) easier, for historical reasons, but also because would make Maven dependency management much harder for users. As dependencies will already be significantly more complex in Search 6 (due to the Lucene integration being moved out of the engine), we didn't want to add to the burden.

I probably could be convinced to move the APIs to separate modules if others think it's necessary and if we do that before Search 6.0.0.CR1, but I'd rather explore alternatives (such as the ones I mentioned above) before we go that route...