Arguments and options are not passed in correct order to method subcommands

[Onedy]

I have a method subcommand in a class subcommand which is added to the main command by commandLine.addSubcommand().
This is my method:

    @Command(name = "subcommand")
    void start(@Option(names = "-r", arity = "0") boolean optionR,
               @Option(names = "-s", arity = "0") boolean optionS,
               @Parameters(arity = "1") String url) {
        System.out.println("Everything OK");
    }

and the command: "test", "subcommand", "-r", "-s", "URL"

The issue is that arguments are passed in wrong order: string, boolean, boolean

Minimal working example:
PicocliTest.zip
Just unzip and run with ./gradlew clean assemble :test --tests "test.MyTest" --info

And look at: java.lang.IllegalArgumentException: argument type mismatch
As you can see, the parsed args are passed in wrong order:

In the other hand, if I define the method as follows (with only one option):

    @Command(name = "subcommand")
    void start(@Option(names = "-r", arity = "0") boolean optionR,
               @Parameters(arity = "1") String url) {
        System.out.println("Everything OK");
    }

and I execute the command: "test", "subcommand", "-r", "URL"
the method is called with boolean, boolean instead of boolean, String

[Onedy]

The first case may be related to #1741, but the second case may be not.

[Onedy]

Also if I define the method as follows:

    @Command(name = "subcommand")
    void start(@Parameters(arity = "1") String url,
               @Option(names = "-r", arity = "0") boolean optionR,
               @Option(names = "-s", arity = "0") boolean optionS,) {
        System.out.println("Everything OK");
    }

and I execute the command: "test", "subcommand", "URL", "-r", "-s"
the method is called with:

instead of "URL", true, true

[remkop]

@Onedy I assume this is all with picocli 4.6.3, but does this issue still occur with the latest picocli main branch? (since that has the fix for #1741)

I won't be able to look at this in detail today.

[remkop]

Thank you for the project to reproduce the problem.
I created an equivalent test that does not use Spring:

package test;

import org.junit.jupiter.api.Test;
import picocli.CommandLine;
import picocli.CommandLine.*;

import static org.junit.jupiter.api.Assertions.*;
import static picocli.CommandLine.ScopeType.INHERIT;

/**
 * https://github.com/remkop/picocli/issues/1774
 */
public class Issue1774 {
    public CommandLine getTestCommandLine(ParentTestCommand parentCommand, TestCommand testCommand, IFactory factory) {
        CommandLine commandLine = new CommandLine(parentCommand, factory);
        commandLine.addSubcommand(testCommand);
        return commandLine;
    }
    @Command(name = "parentTestCommand", mixinStandardHelpOptions = true, scope = INHERIT)
    static class ParentTestCommand {
    }

    @Command(name = "parentTestCommand", mixinStandardHelpOptions = true, scope = INHERIT,
            subcommands = TestCommand.class)
    static class ParentTestCommand2 {
    }

    @Command(name = "test")
    class TestCommand {
        @Command(name = "subcommand")
        void start(@Option(names = "-r", arity = "0") boolean optionR,
                   @Option(names = "-s", arity = "0") boolean optionS,
                   @Parameters(arity = "1") String url) {
            System.out.println("Everything OK");
        }
    }
    @Test
    void testIssue1774() {
        CommandLine commandLine = getTestCommandLine(new ParentTestCommand(), new TestCommand(), CommandLine.defaultFactory());
        assertEquals(0, commandLine.execute("test", "subcommand", "-r", "-s", "URL"));
    }
}

This test fails with picocli 4.6.3, as demonstrated when I add it to the PicocliTest.zip project you provided:

Issue1774 > testIssue1774() FAILED
    org.opentest4j.AssertionFailedError at Issue1774.java:40  <--- test fails with picocli 4.6.3

MyTest > testIssue1774() FAILED
    org.opentest4j.AssertionFailedError at PicocliTest.java:26

2 tests completed, 2 failed

> Task :test FAILED

FAILURE: Build failed with an exception.

However, the test succeeds when I run it with the latest main.
So, I believe that the fix for #1741 also fixes this issue.