To be Reviewed By: August 17th 2020
Authors: Patrick Johnson
Status: Draft | Discussion | Active | Dropped | Superseded
...
Related: ClassLoader Isolation
Problem
Geode is comprised of multiple sub-projects, many of which depend on other sub-projects to work, for example, geode-core may depend on geode-management and geode-membership, which may, in turn, depend on other sub-projects themselves. Normally, this is not a problem because all of Geode's projects are present on the Java classpath at runtime, allowing sub-projects to access classes from other sub-projects as required. However, the changes proposed by the ClassLoader Isolation RFC will result in all sub-projects being loaded as separate modules with different ClassLoaders and no longer being on the system classpath, as they were before.
...
- The implementation of modules in Geode
- Refactoring Geode's sub-projects to break or change any existing dependencies between them
- Adding or removing sub-projects
Solution
The proposed solution is to add a manifest file with a "Dependent-Modules" attribute (or add the "Dependent-Modules" attribute to an existing manifest file) to the jar files of all Geode sub-projects. The "Dependent-Modules" attribute will consist of a space-delimited list of sub-projects required by the current sub-project, in the form {name}-{version}, for example:
...
No anticipated changes to public interfaces.
Performance Impact
No anticipated performance impact.
Backwards Compatibility and Upgrade Path
No backward compatibility impact.
Prior Art
An alternative to this proposal would be to load every sub-project as a module at startup and create dependencies between every module and every other module. While this may solve the problem, it would also largely defeat the purpose of modularizing Geode in the first place.
FAQ
Answers to questions you’ve commonly been asked after requesting comments for this proposal.
Errata
What are minor adjustments that had to be made to the proposal since it was approved?
...