> What does this really mean?

It means that the module containing the Infinispan Integration should not be exposed to the classpath of the application deployment.

> How? Are you saying that there are potentially three Infinispan versions? Where is ORM using Infinispan anyways? As second level cache, right? ORM uses in this case the container bundled Infinipspan version, right (or can it use its own as well)?

Yes there might be N versions of Infinispan around: the point of modules is to make that possible, but we need to maintain strict isolation. Yes ORM uses Infinispan for 2nd level caching, and this might be a different version than the one used by Search, but since Search is being boostrapped by ORM you need to be careful of how we structure modules, and what we expose. The less you expose, the better of course, but classloader handling isn't flawless in neither Hibernate ORM nor Infinispan (therefore I sent to different emails as they pose different challenges). Search needs to workaround limitations of both.

>> but the current module layout is rather leaky it seems;
>What do you mean with that?

As the title of this issue described: our current module is exposing more than needed: we're exposing the Infinispan version used to store the indexes. This should not be needed, but while attempting to make isolation more narrow I've hit those TCCL bugs.