ModeShape 3.x used to have a set of options which allowed clients to provide a JGroups configuration file that would be used when clustering multiple repositories.

With ModeShape 4.x and MODE-2079, this was removed and ModeShape started using Infinispan's JGroups configuration and forking a dedicated a channel off that.

Since ModeShape 5 will not be using Infinispan anymore, there are a two different approaches that can be considered when it comes to providing repository inter-communication in a cluster:
1. store all changes (i.e. events) coming from all the cluster nodes in the database. This essentially means the local journal (which is now optional, local to each cluster node and stored on the FS) would be stored and would be available in a "central" location. Each of the cluster nodes would then have to constantly poll the persistent storage and get a "delta" of the changes coming from all the other cluster nodes and apply this "delta" locally to bring their own data up-to-date.
2. revert partially or totally the changes made as part of MODE-2079 and keep using JGroups as the preferred means of communication across the cluster nodes.

In addition to inter-process communication, the chosen solution has to be able to also provide a way to perform "global cluster locking" which is required by ModeShape when running in a cluster in order to correctly initialize a repository.

While (1) is doable, it would require a lot more changes and would essentially be something completely new. On the other hand, (2) is something that requires far less changes and it's something with which we know ModeShape can work. Also, existing clients which are clustering have already configured JGroups for Infinispan clustering, so the exact same configuration can be reused for ModeShape.

In conclusion, ModeShape 5 should still use JGroups as the preferred clustering infrastructure, even without the Infinispan dependency.