Junit5: Pass command line arguments via file to ConsoleLauncher

[yyoncho]

There is a command line argument limit on OS-es like Windows(8081). So it would be good if it is possible to pass command line arguments to junit-platform-console-standalone via file since the classpath might be very big.

[sormuras]

The implementation c-/should follow most of the features supported javas @file option: https://docs.oracle.com/javase/10/tools/java.htm#JSWOR-GUID-4856361B-8BFD-4964-AE84-121F5F6CF111

[marcphilipp]

@yyoncho Have you tried using the CLASSPATH environment variable instead?

[yyoncho]

@marcphilipp if you try to set env variable you will hit the command line limit again ...

[marcphilipp]

@sormuras Is this @file thing new?

@yyoncho Given @file options, can you already use that like in the following example?

java -cp @my-classpath.txt junit-platform-console-standalone.jar ...

[yyoncho]

@marcphilipp yes, if this is the equivalent to passing the classpath as "--cp" console platform runner param.

[marcphilipp]

@yyoncho Yes, it should be. Could you please give that a try?

[remkop]

If there is interest, I can provide a pull request to replace the current jopt-simple command line parser with picocli. That will give these benefits:

• picocli has built-in support for @-files - this feature request
• usage help with ANSI colors
• TAB autocompletion on bash and zsh
• less code: DetailsConverter, ThemeConverter and UriConverter can be removed (enums and URI conversion are supported out of the box), KeyValuePairConverter can likely be removed (picocli supports Maps out of the box); the builder-style code in AvailableOptions can be replaced with field annotations

In terms of track record, Groovy uses picocli for its standalone tools and recently replaced Commons CLI with picocli in their CliBuilder DSL implementation (see https://blogs.apache.org/logging/entry/groovy-2-5-clibuilder-renewal).

Please let me know if there would be interest in a PR.

[sbrannen]

@remkop, thanks for the offer!

@yyoncho Given @file options, can you already use that like in the following example?

java -cp @my-classpath.txt junit-platform-console-standalone.jar ...

@marcphilipp, I think the request is for @file support for the Console Launcher itself (i.e., not the java executable):

--class-path, --classpath, --cp <Path:         Provide additional classpath entries --
  path1:path2:...>                               for example, for adding engines and
                                                 their dependencies. This option can be
                                                 repeated.

So, if jOpt Simple doesn't support that, perhaps we should consider the proposal from @remkop.

@junit-team/junit-lambda, thoughts?

[sbrannen]

Tentatively slated for 5.3 RC1 though currently only for the sake of _team discussion_.

[remkop]

Out of interest, what is the timeline for 5.3 RC1?

[yyoncho]

@marcphilipp @remkop I tried it with java 8 and it failed to find main class. Just for the record, you cannot use -jar + classpath. Here it is what I tried to use.

java -cp @classpath.txt  org.junit.platform.console.ConsoleLauncher -m xxx.QueryMatcherTest#testString

[marcphilipp]

I tried it with java 8 and it failed to find main class.

@yyoncho What was in classpath.txt?

@marcphilipp, I think the request is for @file support for the Console Launcher itself (i.e., not the java executable)

@sbrannen I know, I was just trying to come up with a workaround. 😉

If there is interest, I can provide a pull request to replace the current jopt-simple command line parser with picocli.

@remkop picocli does look very nice! We're shading/relocating jopt-simple so JUnit users can use a different version of it in their own applications. Would that also be possible with picocli?

[remkop]

@marcphilipp Yes, Groovy and Micronaut are shading picocli in their distributions so it is certainly possible.

[marcphilipp]

@remkop Cool, in that case I don't see a reason why we shouldn't explore this option. So, feel free to submit a PR, if you feel up for it. 🙂

[remkop]

Question about the expected behaviour:

In JOptSimple options are defined without specifying hyphens: parser.acceptsAll(asList("o", "select-module"), .... It appears that JOptSimple accepts any number of leading dashes when recognizing options. The unit tests expect that any option is recognized with one dash as well as with two dashes:

-o com.acme.foo
--o com.acme.foo
-select-module com.acme.foo
--select-module com.acme.foo

This surprised me a bit, since the JOptSimple usage help only shows the "canonical" number of dashes:

-o, --select-module <String: module name>      EXPERIMENTAL: Select single module for
                                                 test discovery. This option can be
                                                 repeated.

In picocli, dashes are explicit when options are defined: @Option(names = {"-o", "--select-module"}, .... In my first cut of a picocli-based ConsoleLauncher, I followed the current usage help message.

However, this doesn’t recognize --o or -select-module, and some existing unit tests fail because of this.

In this version, usage help now looks like this: (https://pasteboard.co/HxwGmsa.png shows the ANSI colors)

  -o, --select-module=NAME   EXPERIMENTAL: Select single module for test discovery. This
                               option can be repeated.

It is possible to simply define all options with both a single dash and with two dashes: @Option(names = {"-o", "--o", "-select-module", "--select-module"}, ..., but these would all show in the usage help:

  -o, --o, -select-module, --select-module=NAME
                             EXPERIMENTAL: Select single module for test discovery. This
                               option can be repeated.

Do you prefer to recognize all options with both a single dash and with two dashes (with a longer usage help message), or is it acceptable to reject user input that does not match the format in the current usage help message?

[remkop]

I thought of a way to keep the current lenient parser behavior and still display the current usage help message. Picocli allows hidden options that are not shown in the usage help.

// shown in usage help
@Option(names = {"-o", "--select-module"}, ...)
List<String> selectModules;

// not shown 
@Option(names = {"--o", "-select-module"}, hidden = true)
List<String> additionalSelectModules;

The values can be merged.

I’ll proceed with this for now. Let me know if you prefer one of the other possibilities I mentioned in my previous comment.

[sbrannen]

Since we want the usage to be backward compatible, let's just go with the "hidden options" approach.

[marcphilipp]

@sbrannen Do you really think we need to keep supporting those? Since they were not documented, I think it would be fine to get rid of those for the sake of maintainability.

[sbrannen]

Hmmm... it's a bit of a tough call.

We could always "just go for it (the removal) and see if anybody complains strongly".

But the support _did_ exist. So technically speaking it would be a breaking change.

And yet... you are of course correct that that support was undocumented.

So I'm OK with only supporting the _documented_ variants if the rest of the team wants to go that route. 😇

[remkop]

I pushed PR https://github.com/junit-team/junit5/pull/1530 for review.

This still has the "hidden options" and follows the jopt-simple behaviour. If there is consensus to only support the documented options I'm happy to make the required changes.

Please take a look and provide feedback when you have time.

[remkop]

PR #1530 for this ticket now includes documentation and passes all tests. Kindly review at your convenience.

[remkop]

It would be great if this could be included in 5.3 RC1. Please let me know if there’s anything I can do to facilitate that.

[marcphilipp]

Fully agreed! I'll review #1530 today.