-
Notifications
You must be signed in to change notification settings - Fork 418
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to standardize command names/aliases #1799
Comments
Actually, based on our earlier discussion in #1665, maybe this can already be accomplished using mixins as below?
Edit: Doesn't seem to work; seems like picocli requires an
|
Yes, that last example is how I intended mixins to be used. What would be required to add support for custom |
@remkop Just has a look at this, I think this should be relatively simple:
I'm just not sure whether |
Alternatively, we could look into the ability to also specify command name through mixins, and not requiring a |
Just had a further look at this, looks like auto-complete and man page generators just create a new However, annotation processors use their own methods for processing |
@remkop Any suggestions on how to best implement this feature? This would really be of big benefit to our CLI application to ensure consistent command names and aliases. For example, we already have 23 For now, best we can do is something like the following, which is cumbersome and easy to forget the mixin: @Command(name=StdCmds.LIST)
public class SomeListCommand {
@Mixin StdCmds.LIST_ALIASES listAliases; // This mixin would have a Command annotation defining the aliases
...
} The ability to define custom annotations annotated with @ListCommand
public class SomeListCommand {
...
} Alternatively, if it's easier to implement, we could remove the requirement to have an public class SomeListCommand {
@Mixin ListCommand listCommand; // Both name and aliases defined through Command annotation on mixin
} Some other alternatives that I've been thinking of, but none of them are really pretty:
|
I won’t be able to spend much time on this, if any. I’m not convinced that this is a very common requirement, but perhaps the ability to have custom annotations is generally useful. However if this ability comes at the price of a lot of complexity then I’m not sure if it is a good trade-off… Any PR to implement this should cover both the runtime reflection and the annotation processor. |
Hi @rsenden, can this ticket be closed? |
Hi @remkop, given our current codebase, support for custom annotations probably wouldn't provide much value anymore. However, it would still be useful if command name could be defined through a Our code currently looks something like this, having a separate mixin for each type of command ( @Command(name=BasicOutputHelperMixins.List.CMD_NAME)
public class ProxyListCommand extends AbstractBasicOutputCommand implements IRecordTransformerSupplier {
@Mixin @Getter private BasicOutputHelperMixins.List outputHelper;
...
} public class BasicOutputHelperMixins {
@ReflectiveAccess @Command(name = "list", aliases = {"ls"})
public static class List extends AbstractBasicOutputHelper {
public static final String CMD_NAME = "list";
@Getter @Setter(onMethod=@__({@Spec(Target.MIXEE)})) private CommandSpec mixee;
@Getter @Mixin private OutputWriterWithQueryFactoryMixin outputWriterFactory;
@Getter private StandardOutputConfig basicOutputConfig = StandardOutputConfig.table();
}
...
} Now we need to explicitly have We already did something similar for 'inheriting' aliases in #1836, however I guess defining and using the command name defined on a |
Our picocli application has a structure similar to the following:
To ensure a consistent command hierarchy, we want to standardize the command names, aliases and possibly other command attributes.
For command names, we can easily create a constants class and then use for example:
@Command(name=StandardEntityCommands.DELETE)
Unfortunately, this is not possible for aliases as you cannot refer to array constants from annotations; the following doesn't work:
@Command(name=StandardEntityCommands.DELETE, aliases=StandardEntityCommands.DELETE_ALIASES)
You could do something like the following, but then you won't be able to easily add or remove aliases:
@Command(name=StandardEntityCommands.DELETE, aliases={StandardEntityCommands.DELETE_ALIAS1, StandardEntityCommands.DELETE_ALIAS2})
I think the best way to accomplish this is to allow for creating custom
Command
annotations that specify default values for the various@Command
attributes, i.e.Any chance something like this could be implemented, properly supporting auto-complete and man-page generation? Any other way to reuse command attributes across multiple command implementations?
The text was updated successfully, but these errors were encountered: