Question: Multiple invocations of execute method on single CommandLine instance #2066
Comments
|
Could you provide a small program that reproduces this issue? |
|
Yes CommandLine instances are meant to be reusable across With the example to reproduce it, please also provide the output of running it with tracing set to DEBUG. I suspect the workaround will be to use an explicit |
|
@remkop It looks like ArgGroups are causing this issue, and setting Tested with picocli 4.7.4, the code below results in the following output, showing that options 3 & 4 haven't been reset to null values: import picocli.CommandLine;
import picocli.CommandLine.ArgGroup;
import picocli.CommandLine.Command;
import picocli.CommandLine.Mixin;
import picocli.CommandLine.Option;
public class PicoTest {
public static void main(String[] args) {
CommandLine cl = new CommandLine(MyCmd.class);
cl.execute("--o1", "v1", "--o2", "v2", "--o3", "v3", "--o4", "v4", "--o5", "v5");
cl.execute();
}
@Command(name="test")
public static final class MyCmd implements Runnable {
@Option(names = "--o1") private String o1;
@Mixin private MyMixin mixin;
@ArgGroup(exclusive=false) private MyArgGroup2 argGroup;
@Override
public void run() {
System.out.println(String.format("o1: %s, o2: %s, o3: %s, o4: %s, o5: %s",
o1, mixin.o2, mixin.argGroup.o3, argGroup==null?null:argGroup.o4, argGroup==null?null:argGroup.o5));
}
}
public static final class MyMixin {
@Option(names = "--o2") private String o2;
@ArgGroup(exclusive=false) MyArgGroup1 argGroup = new MyArgGroup1();
}
public static final class MyArgGroup1 {
@Option(names = "--o3") private String o3;
}
public static final class MyArgGroup2 {
@Option(names = "--o4") private String o4;
@Option(names = "--o5", defaultValue = Option.NULL_VALUE) private String o5;
}
}Debug trace: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is a single
CommandLineinstance supposed to be reusable for multiple invocations of theexecutemethod? I.e. should something like the following be supported?In our application, it looks like the second invocation of
cmdalso hasvalue1set for--opt, causing unexpected behavior. In case it matters,--optis defined in a mixin.The text was updated successfully, but these errors were encountered: