Move
...
gfsh code to a separate gradle sub-project
Superscript Authors: Jens Deppe, Patrick Johnson
Status: Discussion Implemented
Superseded by: N/A
Related: N/A
...
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.
...
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.
Initial investigation has highlighted the need for at least the following changes:
RebalanceCommand
(a gfsh command which will need to be moved into the new package) is directly coupled toRebalanceCommandOperation
which is part of the new Cluster Configuration Management service.RebalanceCommand
will need to be refactored to remove the coupling.CliStrings
contains many constants which are used in various places throughout the management code. Our initial thought is that all cli-specific strings (for example: command help strings) will remain in this class and be moved into the new module and any common strings will be moved into a class in geode-core.CliUtils
contains various static methods which are mostly helper methods to ease executing functions and discovering members. Our initial though is that commonly useful methods will be moved into a newManagementUtils
class and the gfsh-dependent functions will remain inCliUtils
and be moved into the new package.
Performance Impact
There is no expected performance impact
...
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.
...