jbock-java / jbock Goto Github PK

All annotations should get an additional attribute "description", similar to jcommander and picocli. Javadoc reading will be a fallback where this attribute is not set.

Specifying a mapper class which has a type parameter E and implements Supplier<E> leads to an uncaught exception at compile time.
Fixed in 59e52bc

I have a use case where I'd like to add/remove an option based on the presence/absence of a module on the classpath. I'm assuming this is impossible to do this at compile-time, but alternatively, hiding an option from the usage printout should be possible at runtime.

One way I imagined this could be possible by calling StandardErrorHandler's printUsageDocumentation using a different CommandModel with fewer elements, but cloning or modifying the command model is currently not possible afaik.

Rename annotations to make the API more appealing:

• CommandLineArguments -> CLI Command
• Parameter -> Option
• PositionalParameter -> Param

for example: Param.isList should either take a VariableElement or a TypeMirror

Creating the command instance via constructor doesn't work if there are more than 255 options.

Attributes can always be inferred:

1. collector absent, mapper returns optional type -> optional
2. collector absent, mapper returns list -> repeatable
3. collector absent, mapper returns anything else but boolean -> not optional, not repeatable (~required)
4. collector present -> repeatable, not optional; explanation:
   1. collector doesn't return optional type -> repeatable, not optional
   2. collector returns optional -> repeatable (otherwise collector won't be used), not optional (otherwise collector won't be used)

In 2.8.4, and possibly some of the previous 10 or so revisions, the generated code for positional parameters can't handle the empty string, causing a stacktrace and no useful message at runtime.
Fixed in d74fb71

Tested in 4.1.000, affects versions since 4.0.000

This examples cause an uncaught AssertionError during compilation

@Command
abstract class BadCommand {

    @Parameters(converter = MyConverter.class)
    abstract Integer something();

    static class MyConverter implements Function<String, Integer> {

        @Override
        public Integer apply(String s) {
            return Integer.parseInt(s);
        }
    }
}

If the type of the collector is

<E, F> Collector<E, ?, List<F>>

so F can be inferred from the parameter but E is still free.
This is currently not allowed, but should be.
The mapper can be any function that accepts strings, for example:

Function<String, String>
<V> Function<String, V>
<V> Function<V, V>
<V> Function<V, List<V>>
<V, T> Function<V, T>

• program description from javadoc
• hide stacktrace by default

Not really clear how @Command and @SuperCommand can/should be used in combination. Would it be possible to get an illustrated example (in the wiki or in the examples folder)? I'd say "git" is a good example of command to illustrate the expected behaviour.

in constructor, as an alternative to String

seems to cause dagger bug