Page History

...

The ClassLoader Isolation RFC proposes that each sub-project of Geode be loaded as a separate module using JBoss Modules. This means that the classpath shown above will become much shorter as the majority of sub-projects, along with their library dependencies, are removed from it and put into modules with separate ClassLoaders. Note that this is only the case for servers and only if you opt-in; the current way of working will remain default behavior and clients will be unaffected. The new classpath when opting for the new modular behavior will look something like this:

...

Notice that only project dependencies and only those scoped to be required at runtime (runtime, runtimeOnly, compile, implementation, and api) are included in "Dependent-Modules". This is because the list is generated from the r. Other library dependencies are excluded because they will not be loaded as separate modules (though that may change in future iterations) and dependencies scoped as compileOnly or test are excluded because they are not required in production. You may also notice that the "Dependent-Modules" list contains modules that are not explicitly included in Gradle, specifically geode-tcp-server, geode-http-service, geode-common, geode-management, and geode-unsafe. These modules are included in the list because they are required by other modules that are explicitly called out in Gradle and therefore, are part of the module's runtime classpath. Generating the "Dependent-Modules" list like this results in the following relationships between modules: 

...