Turns out my above expressed concerns about abandoning WildFly users don't really apply in this case as we happen to be able to build with ORM 5.1 and still be compatible with ORM 5.0, so let's move on with the update.

The upgrade to ORM 5.2 won't be as simple though.

This would imply that when we finally release the Elasticsearch features, the Wildfly users won't be able to use it without also facing the complexity of overriding the ORM modules.

At the very least it means that Hibernate Search would also need to ship the ORM modules to allow it.. that would be a strong reason to contribute the ORM modules packaging to the ORM project.

My preference really is to keep it simple for users, and make sure that modules released with Search "just work" with the WildFly version of ORM. Not least remember that Jipijapa injects various other services, and it won't do that for custom packages of ORM. Could we find an alternative to have OGM move forward w/o needing this?

I also see value in allowing users of "latest Search" to use "latest ORM" so it's indeed a puzzling subject. Afaik we're able to keep compatibility with bot versions of ORM, so maybe we should ship multiple versions of the modules?

Remember that it's totally possible for power users to package Hibernate Search within their own deployment.

Hey , can we do it in the course of 5.6 Beta2? For Hibernate OGM 5.1 to work with ORM 5.1, we need a HSEARCH version based on 5.1, too, otherwise we'd have to override the HSEARCH modules as the ORM versions in use would be in conflict.