Allow empty mixin (Not urgent)

[nakanaka7]

I found a mixin without any annotations (@ Option, @ Parameters, etc) will invoke picocli.CommandLine$InitializationException. I tried using such "empty" mixin in the following situation.
real situation

public class BaseCommand implements Runnable {
  @Command
  private void subcommandA(@Mixin MixinA mixinA) {
    runSubcommand(mixinA)
  }
  @Command
  private void subcommandB(@Mixin MixinB mixinB) {
    runSubcommand(mixinB)
  }
  @Command
  private void subcommandC(@Mixin MixinC mixinC) {
    runSubcommand(mixinC)
  }
     .......... 

  private void runSubcommand(IMixin mixin) {
    //invoke Imixin method 
  }

IMixin is an interface. MixinA, MixinB, MixinC... are the implementation of IMixin. The implementations are basically real mixin, but a few case are empty mixins.
I could avoid the exception easily by creating the instance directly as following. But allowing such empty mixin will help code
consistency like above.

  @ Command
  private void subcommandD() {
      runSubcommand(new MixinD())
  }

[remkop]

@nakanaka7 Have you tried annotating the empty mixin with just @Command?
That may prevent the InitializationException.

[nakanaka7]

It works fine. Thank you.

[rsenden]

@remkop I'm having a similar issue; in my case the mixin is not empty but provides generic option processing functionality based on mixee.options().

Good to know that the @Command annotation can be used as a workaround, but it feels a bit odd to annotate a mixin with @Command. Any chance that picocli can be improved to allow for mixins that do not have any options or parameters?

Alternatively, can we have a more appropriate annotation that is accepted by the validateCommandSpec method? Maybe we could just add ElementType.TYPE to the list of targets for the @Mixin annotation, to allow mixins to be explicitly declared as being a mixin, and update validateCommandSpec accordingly?

[remkop]

@rsenden
The @Command annotation is not a workaround, this is the design. It allows you to mix in command attributes like header, footer, version, etc. All command attributes can be mixed in, so creating another separate annotation would then have to also have all these attributes…

Reusing the @Mixin annotation would also mean that this annotation would need all attributes from the @Command annotation…

(I actually don’t understand what problem we are trying to solve here…) 😅

[rsenden]

@remkop I wasn't (actively) aware that you could use the @Command annotation to mix in command attributes, so for that purpose it indeed makes sense to have an @Command annotation on mixins.

In cases like described in this issue, we are not trying to mix in command attributes though, so in that regards it makes less sense to add an empty @Command annotation. For the uneducated reader, this may look like you are defining a command rather than a mixin.

Anyway, I can live with adding the @Command annotation to such mixins, I'll probably add a comment to explain why though ;)