imo, I think that GFSH is Spring Shell, it should really only be
commands that are registered inside of META-INF.services .. aka
implements CommandMarker.
This way we has standard simple way to specify commands.
--Udo
On 5/25/17 11:52, Jared Stewart wrote:
I would like to propose that we eliminate the “user-command-packages” system
property, in favor of scanning the entire classpath to find commands.
To give more detail, Geode currently supports three ways to load GFSH commands:
Scan the classpath for commands in
"org.apache.geode.management.internal.cli.commands”
Scan the classpath for commands in a package specified by a user via the
“user-command-packages” system property.
Scan the classpath for commands registered in files inside META-INF.services (e.g.
"geode-core/src/test/resources/META-INF/services/org.springframework.shell.core.CommandMarker”)
We have some bespoke code responsible for scanning the classpath
(ClasspathScanLoadHelper) that I am in the process of replacing with
FastClasspathScanner (GEODE-2989). Since FastClasspathScanner will no longer
need to eagerly load all of the classes in the target package, I don’t see any
reason why a user should need to specify a “user-command-package” property or a
“META-INF/services” file. Instead, we should just scan the whole classpath and
register any commands that we find.
Thoughts?
