Move membership code to a separate gradle sub-project

Authors: Jens Deppe, Patrick Johnson

Status: Discussion

Superseded by: N/A

Related: N/A

Problem

Geode currently has a hard dependency on Spring libraries as a result of gfsh being developed against the spring-shell library.

We would like to extract gfsh and related cli code into a separate module such that Geode can be run without gfsh as part of the core if so desired. This decoupling will have various benefits:

• Removal of Spring dependencies from Geode core.
• Clearer understanding of which components rely on Spring.
• Clear separation of various generations of admin frameworks. As the newer Cluster Configuration Management functionality reaches maturity, users will be able to easily chose which functionality they wish to include.

Anti-Goals

• It is not a goal to provide a standalone gfsh utility

Solution

We will create a new gradle subproject called geode-gfsh-cli. Ideally, all of the code in the org.apache.geode.management.internal.cli package and related unit tests, will be moved out of geode-core and into geode-gfsh-cli. geode-gfsh-cli will have a dependency on geode-core.

JMX management functionality will be unaffected except for the ability to execute gfsh commands via the MemberMXBean.processCommand method. 

Changes and Additions to Interfaces

This proposal does not add or remove any public API.

A new CacheService will be added called CommandProcessor which will enable the MemberMXBean.processCommand functionality.

The current mechanism to detect commands will not be changed, however the functionality will also be moved into the new module. Currently this involves scanning the classpath for classes implementing the org.springframework.shell.core.CommandMarker interface. Any user-created gfsh commands will need to depend on the new geode-gfsh-cli module.

Performance Impact

There is no expected performance impact

Backwards Compatibility and Upgrade Path

These changes will maintain backwards compatibility with rolling upgrades.

This change will introduce a new optional geode-gfsh-cli maven artifact. Users building a classpath with maven/gradle/etc. will need to explicitly include this artifact if they wish to use gfsh commands.

Prior Art

There have been multiple proposals to make geode more modular  - Geode Modularization Proposal (work in progress), Proposal for Geode Modularization. This proposal can be considered an incremental step in that direction.

FAQ

Q: Why not create a standalone gfsh utility?

A: A proof-of-concept, using a Spring Boot jar approach, for such a thing has been created. It requires bundling all of Geode dependencies, including war files, into a single jar resulting in a ~120MB artifact. This proposal does not preclude ever doing that, but it is not a current goal.

Errata

What are minor adjustments that had to be made to the proposal since it was approved?