While working on HSEARCH-3550 In Progress and making our Java module integration tests more relevant, I stumbled upon a blocker: when Hibernate Search is actually declared as a dependency of a module and when this module is actually run in the modulepath, Hibernate Search doesn't boot... It looks like declared services are not found by ORM, so both the integrator and the "Hibernate Search service context" do not exist as far as ORM is concerned.

A possible explanation below.

When running an application in the modulepath, this application will declare dependencies to Hibernate Search and Hibernate ORM in its module-info.java. As a result, both Hibernate Search and Hibernate ORM will be automatically promoted to (automatic) modules and put in the modulepath.

Since Hibernate Search and ORM are now modules, unfortunately they have to comply with all the module rules, even if they are just "automatic modules". This means no split packages (so far so good), but more crucially this means services must be declared in a module-info.java...

This sounds a bit strange, as it basically means automatic modules cannot provide services: classpath JARs can, and full modules can, but not automatic modules since they would need a module-info.java and therefore wouldn't be automatic modules anymore.

But as far as I can tell, it's exactly how it's intended to work. While diving in the code, I was able to determine that Hibernate Search services were being ignored because of this code in java.util.ServiceLoader.LazyClassPathLookupIterator#hasNextService:

                    if (clazz.getModule().isNamed()) {
                        // ignore class if in named module
                        continue;
                    }

Which, well, seems pretty clear to me.

We should investigate a bit more, but if this really turns out to be true, we will need to implement HSEARCH-3274 In Progress in order for Hibernate Search to be really usable in an application that declares a module-info.jar.