Giter Club home page Giter Club logo

airline's Introduction

Airline

Airline is a Java library providing an annotation-based framework for parsing command line interfaces.

It supports both simple single commands through to complex git style interfaces with groups and sub-groups.

Additionally it provides many powerful features including, but not limited to, the following:

  • Highly customisable Parser
  • User Defined Aliases
  • Annotation driven restrictions framework to reduce boilerplate
  • Extensible Help system supporting multiple output formats including
  • generating Man pages and Bash completion scripts
  • Maven Plugin for validation and help generation
  • during builds

User Guide

Our project website at http://rvesse.github.io/airline/ contains a fairly comprehensive user guide. Some portions are still under development but it covers the vast majority of the features of the library.

Usage

To use airline you need to add a dependency to it to your own code, the Maven artifacts are described later in this ReadMe.

You then need to use the various annotations to annotate your command classes:

  • @Command is used to annotate classes
  • @Option is used to annotate fields to indicate they are options
  • @Arguments is used to annotate fields that take in arguments
  • @AirlineModule can be used to modularise option definitions into separate classes

Please see the examples module for a range of examples that show off the many features of this library and practical examples of using the annotations.

Or for a quick tutorial why not read our Introduction to Airline in our User Guide.

Quick Examples

Single Commands

Simply create a parser instance via SingleCommand.singleCommand() passing in a class that is annotated with the @Command annotation e.g.

    public static void main(String[] args) {
        SingleCommand<YourClass> parser = SingleCommand.singleCommand(YourClass.class);
        YourClass cmd = parser.parse(args);
        
         // Execute your command however is appropriate e.g.
         cmd.run();   
    }

Multiple Commands

Create an instance of a Cli, this can be done either using the CliBuilder or by annotating a class with the @Cli annotation. This is somewhat more involved so please see the User Guide or the examples module for proper examples.

Executable JAR

Note that typically you will want to create an executable JAR for your CLI using something like the Maven Shade plugin.
This will then allow you to create a simple wrapper script that invokes your CLI.

#!/bin/bash
# myapp

java -jar my-app.jar "$@"

Note: You must use "$@" here as otherwise Bash may expand/interpret arguments and as a result the JVM may not receive the expected arguments that the user enters.

If this is done you can then invoke your application e.g.

 myapp --global-option command --command-option arguments

Or:

myapp --global-option group --group-option command --command-option arguments

License

Airline is licensed under the Apache Software License Version 2.0, see provided LICENSE

See provided NOTICE for Copyright Holders

JDK Compatibility

As of 3.0.0 Airline requires Java 11, see [guide/practise/jdk.md] for more details.

Maven Artifacts

This library is available from Maven Central with the latest stable release being 3.0.0

Use the following maven dependency declaration:

<dependency>
    <groupId>com.github.rvesse</groupId>
    <artifactId>airline</artifactId>
    <version>3.0.0</version>
</dependency>

Snapshot artifacts of the latest source are also available using the version 3.0.1-SNAPSHOT from the OSSRH repositories.

Build Status

CI builds are run on Travis CI Build Status, see build information and history at https://travis-ci.org/rvesse/airline

Historical Information

This is a substantially rewritten fork of the original airline library created based on improvements predominantly developed by myself plus some minor improvements taken from the Clark & Parsia fork. It has significantly deviated from the original library and gained many powerful features that differentiate it from both the original and other libraries with similar goals.

Migrating between Versions

Airline 2 contains significant breaking changes from Airline 1.x, please see Migrating.md for more details on how to migrate code forward.

Airline 2.1 contains some further minor breaking changes that should only affect advanced users, again please see Migrating.md for more details on how to migrate code forward. Some users may need to add additional Maven dependencies if they were using help formats other than the basic CLI help.

Airline 2.2 has some minor breaking changes that may affect users of the @Arguments annotation, again please see Migrating.md for more details.

Airline 2.9 has some changes to composition in preparation for future breaking changes, most notably introducing the @AirlineModule annotation as a replacement for @Inject. It remains backwards compatible with prior 2.x releases but users may wish to start making changes to ease future transitions.

Airline 3.0.0 has several major breaking changes, this includes updating the minimum JDK version to 11, making some dependencies optional and much improved JPMS compatibility.

airline's People

Contributors

cheddar avatar dain avatar dodie avatar electrum avatar gsmet avatar gtarkin avatar incredible-io avatar jfallows avatar johngmyers avatar lanwen avatar martint avatar rkhaja avatar rvesse avatar sdorra avatar the-alchemist avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

airline's Issues

Restrictions help hints not output in a deterministic order

Noticed this in our internal use of airline

Where a option/argument has multiple restrictions apply to it and these all provide help hints the order in which these hints get included in the help output is nondeterministic.

This means that generating the help multiple times can produce slightly different output each time. In order to avoid this we should ensure that the processing of help hints enforces a deterministic order e.g. Based upon the class of restriction

Add support for console colorisation

Console output can be colorised using appropriate ANSI control sequences. It would be useful to provide some helper methods/classes for working with colorised output

Merging options should actually allow merging options

Currently the code only merges options from class hierarchies where those options do not collide on name.

In some cases it would be useful to actually allow merging options properly e.g. to make a hidden option visible in a derived command or hide an irrelevant (or on by default) option in the derived command. Or a derived command may want to expand on something like the description, add extra synonyms for the option etc.

Obviously care needs to be taken to not merge clearly incompatible options (different types) and not to make non-sensical merges but this seems like this should be doable and very useful.

Discussion should be an array

For @Command annotations the discussion parameter should be an String[] to make it easier to enter extended discussion notes

Remove Guava dependency

While Guava gives us a lot of useful stuff it causes a lot of issues because of poor versioning and compatibility between versions (e.g. apache/jena#87)

We should strip out all usage of Guava for Airline 2

Add an @Version help annotation

It would be useful to have an easy way to inject a Version details section into help via an @Version annotation e.g.

@Version(
  source = "version.properties", 
  versionProperty = "version",
  buildProperty = "build",
  commitProperty = "commit",
  dateProperty = "buildDate",
  additionalProperties = { "author" }, 
  additionalTitles = { Author }
)

Where source specifies some class path resource from which to extract the data (must be a properties file) and the other fields specify the fields from which to extract the relevant data

Add a bash launcher generator

Add a new global usage generator that simply generates a script that can be used to launch the resulting Java CLI.

Would need the following info:

  • Name of the JAR to execute
  • Main class, if omitted assume an executable JAR with a manifest defined main file
  • Relative path to JAR (relative to where the script will live)

Support sub-groups

Changes necessary:

  • Make sure whitespace is forbidden in group names
  • Add .getSubGroups() to GroupMetadata and modify constructor signature as needed
  • Add .withSubGroup() to GroupBuilder
  • Support using whitespace in group names in @Group and @Groups annotations to create sub-groups e.g. foo bar would create a group bar that is a sub-group of the group foo OR would place a command into that group
  • Update parser to be able to support sub-groups
  • Update help generators to cope with sub-groups (this is probably the biggest piece of work)

Add additional restrictions

Now #25 is complete we can start adding additional restrictions, the following are the suggestions:

  • @Once, @MaxOccurrences - Limit the number of times an option may be specified, @Once is synonym for @MaxOccurrences(max = 1)
  • @MutuallyExclusiveWith - May not be specified if some other option(s) are specified
  • @RequireSome - Require at least one of some set of options
  • @RequiredIf - Required if another option is present
  • @DoubleRange, @FloatRange, @LongRange, @ShortRange, @ByteRange - Numeric ranges
  • @LexicalRange - Lexical range
  • @AllowedValues - Similar to @AllowedRawValues but given values are converted into Java types before being compared

Support specifying global restrictions by annotation

Currently global restrictions can only be specified either via the @Cli annotation where they are referenced by class or via CliBuilder where they are passed as instances.

It would be nice if these could also be specified by providing annotations on your @Cli annotated class

This will require adding a GlobalRestrictionFactory and using ServiceLoader to auto-detect them in RestrictionRegistry. The MetadataLoader will also need to look for global restrictions when loading the meta-data for @Cli annotated classes.

Refactor how option restrictions are implemented

Currently we support two kinds of option restrictions:

  • Marking them as required
  • Marking them as having allowedValues i.e. restricted set of values

Ideally we'd like to support a wider range of restrictions e.g.

  • Marking options as mutually exclusive with other options
  • Required if other options are present i.e. requirement dependencies
  • Range restrictions (min and max values)

Rather than keep adding stuff to the @Option annotation it would be better to create a new @OptionRestriction annotation (and sub-classes thereof) which would be used to annotate fields to indicate restrictions that apply. These could then be discovered via reflection and added to the OptionMetadata for an option.

@Pattern should support friendly explanation for Help Hints

While the @Pattern restriction annotation allows for very powerful restrictions upon the value of an option or argument the resulting error messages may not be particularly helpful to end users. Therefore this annotation should support an optional field that allows a developer to specify a friendly explanatory text that describes the intent of the restriction more clearly

Support File and Directory related restrictions

It would be useful to have restrictions that allow you to enforce that an arguments file be a valid path to a file/directory e.g.

@File(mustExist = true, writable = false)

@Directory(mustExist = true, writable = true)

As a related point it would be useful to be able to have File be a valid type for options

Global options seems not to work

Hi,

I have a GlobalOptions module and an abstract Command class where I inject this module into, like in the GalaxyCommand test unit. My first command inherits from this abstract Command and the printed help text shows my global options in a correct way. But when I execute myapp --globaloption all I get is the help text.
Am I missing some parser setting? How is the correct way to get my command's run() method called?

Regards,
Christian

Support partial restrictions

Currently when a restriction is applied to an @Option or @Arguments field it is enforced on every value that the option/argument takes regardless of the arity of said option

It would be nice to be able to specify a restriction that only applies to a specific value e.g.

@Option(name = "--example", arity = 2)
@PartialRestriction(index = 0, restriction = @NotBlank)
private List<String> examples;

Note that the above approach may not work because I'm not sure we can specify that the restriction field takes any annotation (though if we can that would be great)

The other approach would be to add an appliesTo field to all the existing restrictions where -1 indicates applies to all (the current default behaviour) and a positive integer indicates it applies to only the specific value

Support for simple config files

I have a project that using airline, and it works really well. A few of the command args are pretty short and sweet, e.g. hostname, port, but a few are potentially longer, e.g. a list of globs to whitelist/backlist files that the command processes, e.g.:

foo -h host -p port --exclude build,bin,whatever --include '*.txt,src,baz'

For just a few exclude/include args, it's not a big deal, but it seems like it would quickly become cumbersome, especially if the user invokes it on a regular basis, so I'd like to have an option to use a .foorc config file, with some sort of syntax like:

foo.exclude = build,bin,whatever
foo.include = *.txt,src,bar

Musing about what would be simplest for my program, it would be pretty awesome if airline could use the same @Option config I've setup for the CLI arg parsing to also pull in an optional config file.

Does this seem like a good idea? Or too much out of scope? If so, any hints/ideas about other ways/libraries you've seen that might do this?

Remove find bugs annotations

Currently we still have google FindBugs as a dependency which is LGPL. It would be useful to rip out the LGPL dependency and the annotation usages throughout the code base

Make extra help sections discoverable

Similar to how #26 is implementing configurable and extensible restrictions we should use a similar system for help so that arbitrary extra sections may be added to commands and automatically honoured by the built-in help generators

Make options parsing style configurable and pluggable

Currently the parser machinery supports several option parsing styles but these are all hard coded and they are not in any way pluggable

It would nice for them to be pluggable so people could easily add new parsing strategies as they wish, for example using a different separator character for --name=value style options or parsing the values as comma separated values rather than single tokens.

Support `@Cli` and `@Parser` annotations

It would be nice to be able to declare a CLI purely through annotations, this would be particularly useful when using SingleCommand because it could also look for @Parser annotations on the command classes

Support converting to Java types from multiple string values

Currently Airline maps each argument passed in to a single Java type. In some cases it would be nice for multiple string values to be combined into a single type, this would make it possible to instantiate much more complex types than is currently possible.

Doing this would require changes to the following:

  • Need to be able to annotate that an option/argument should convert values in batches
    • If we allow batch sizes that are not equal to the arity also need to annotate that
  • Option and argument parsing needs to take the conversion batch size into account
  • Type converters need to change their signature to accommodate this

Support `arity` for `@Arguments`

Currently @Arguments is unbounded which is the desired default behaviour however sometimes it would be useful to be able to restrict the arity of arguments.

This is particularly true because when using @Arguments unrecognised arguments get treated as arguments rather than errors which can lead to unexpected behaviour

Deprecate and remove arity on @Arguments

Currently @Arguments supports an arity field which actually acts as a constraint on the maximum arity of the arguments rather than specifying how many values are expected. This is confusing because it differs from what the arity field on @Option does.

Since we now have the restrictions system and specifically the @MaxOccurrences annotation it would be better to deprecate this field and encourage use of the appropriate restriction annotation instead.

Therefore it is proposed to deprecate it in 2.1.x and then remove it in 2.2.x

Support git style command aliasing

It would be nice to support an optional command aliasing functionality which would allow users to specify aliases for given command and option combinations they frequently use a la git

This would be an opt-in feature, users would provide the path to a configuration file location (or use a default of ~/.program/program.config if not specified) which can define aliases. Aliases should be added to top level commands and cannot redefine built in groups/commands.

Support declaring a default option

In the cases where you have a command with @Option declarations but no @Arguments it would be nice to be able to declare one of the options as the default so users could omit the option e.g.

example --option value

Should be simplifiable to:

example value

The restrictions on this should be as follows:

  • Command cannot have @Arguments
  • Only one @Option can be declared the default
  • Default option must have an arity of 1

Provide an Airline user guide

Currently Airline is fairly esoteric with no real user guide to teach people how to use the library

We should use GitHub pages and Jekyll to start putting together such a user guide

Content to create:

  • Core Annotations
    • @Cli
    • @Command
    • @Groups and @Group
    • @Parser and @Alias
      • New force built in feature
      • resource locators for user aliases
    • @Option
    • @Arguments
  • Restrictions
    • Range Restriction Annotations
    • @Partials
    • Global Restriction
    • Custom restrictions
    • Annotations from #73
      • @PortRange and @PortRanges
      • @StartsWith
      • @EndsWith
      • @File and @Directory
      • @Positive and @Negative
      • @LengthRange and @ExactLength
  • Help System
    • Custom help sections
    • Hints
    • Formats
    • Bash Completion
  • Error Handling
  • Parser
    • Various new features introduced to @Parser
    • Option Parsing
    • User Defined Aliases
    • Resource Locators
      • Custom Resource Locators
  • Unit Testing
  • Maven Plugin
    • validate goal
    • generate goal
  • Fluent API
    • CliBuilder
    • ParserBuilder

Support grouping options by category in help generators

Requires adding a new category property to the @Option annotation (or a separate @OptionCategory) annotation to state category information

Help generators would then use this additional optional information to group options together in their outputs

Add a RONN generator which generates separate files for each command

For more complex command lines it is more useful to avoid having one enormous man page and instead have a high level summary page that refers to other man pages for each sub-command.

This is somewhat awkward with the API as it stands because it assumes being passed a single writer so this will have to be implemented as multiple classes. The existing RonnCommandUsageGenerator can be re-used to generate the RONN for each sub-commands man page and we'll need a new RonnMultiPageGlobalUsageGenerator to create the overview page and will call the RonnCommandUsageGenerator and direct the outputs of that to the necessary files.

Support an @SeeAlso annotation

When generating help for CLIs we already generate a basic see also section with references to the CLI itself. It would be nice if commands could have a @SeeAlso annotation that would allow them to reference other related commands within the CLI and more generally e.g. System commands i.e. ls, cat etc.

Provide a Maven plugin for generating help during a build

It would be useful in some scenarios to have help generated from an Airline powered CLI during the Maven build process. Ideally this would be done as a Maven plugin so that we could run automatically during the build without having to resort to some indirection (e.g. using the Maven Ant-run plugin)

The plugin should have the following characteristics:

  • MUST be run in the package phase (or later) since it will need access to the compiled code in order to generate help
  • MUST support specifying which classes to generate help for
  • MUST support generating global, group and command help
    • If group/command help is requested for a CLI then pass in each group/command from the CLI to the help generator
    • SHOULD allow for configuring this as desired e.g. generate help for a CLI uses a command help generator
  • MUST allow for specifying which help generator to use
    • SHOULD have sensible default behaviour
    • SHOULD provide a simple <style> setting that specifies one of the built-in help generators i.e. cli, man, html, markdown
    • SHOULD allow for pulling in custom help generators that are not otherwise dependencies of the code being built
    • MUST allow for passing in parameters to the help generator e.g. whether to include hidden groups, command, options and arguments
  • MUST allow for specifying the output directory
  • MAY allow for generating multiple kinds of help at the same time

TroffPrinter does not handle special characters in Java strings

More specifically I have found a case where help annotations contain a \t to indicate a tab character and the Basic help displays correctly but the manual page help prints the \t literally resulting in incorrect Display.

I am not sure if this is actually a bug on our part or if the annotations should be using a literal tab rather than the Java escape

Help of Bash Complemention

Hi,

Thanks for this amazing project! I am using the airline library for the CLI of the ontop project. It works very well.

I noticed airline supports bash completion and want to use it in my project. However, I am not sure how to use it. I attached the @CompletionBehaviour annotations to some of the fields, but it seem not work.
I guess I also need to generate a bash_completion file for bash. Maybe I overlooked something, but I searched around and could not found a guide. Is there some document or example code?

Thanks in advance

Support specifying multiple titles for options

Currently the title field of the @Option annotation only takes a single String which makes it less useful when you have options with arity > 1

It would be good if this was changed to take a String[] and relevant consumers i.e. help and restrictions were appropriately updated to take advantage of this extra information

Note that from a user perspective this change will not be breaking because Java allows array fields in an annotation to be specified as either a single value or as an array initialiser

Tests problems

Hi
I'm getting:

Tests run: 370, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.195 sec <<< FAILURE! - in TestSuite
occurrences_bad_too_many_02(com.github.rvesse.airline.restrictions.TestOccurrences)  Time elapsed: 0.007 sec  <<< FAILURE!
com.github.rvesse.airline.parser.errors.ParseRestrictionViolatedException: Option 'b' must be specified at least 2 times but was only found 0 times
        at com.github.rvesse.airline.restrictions.common.OccurrencesRestriction.postValidate(OccurrencesRestriction.java:61)
        at com.github.rvesse.airline.parser.command.SingleCommandParser.validate(SingleCommandParser.java:96)
        at com.github.rvesse.airline.parser.command.SingleCommandParser.parse(SingleCommandParser.java:44)
        at com.github.rvesse.airline.SingleCommand.parse(SingleCommand.java:100)
        at com.github.rvesse.airline.SingleCommand.parse(SingleCommand.java:95)
        at com.github.rvesse.airline.restrictions.TestOccurrences.occurrences_bad_too_many_02(TestOccurrences.java:42


Running com.github.rvesse.airline.help.markdown.TestHelpMarkdown
Configuring TestNG with: TestNG652Configurator
Tests run: 8, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.632 sec <<< FAILURE! - in com.github.rvesse.airline.help.markdown.TestHelpMarkdown
user_aliases_help_markdown(com.github.rvesse.airline.help.markdown.TestHelpMarkdown)  Time elapsed: 0.021 sec  <<< FAILURE!
java.lang.AssertionError: expected [# NAME

`test` -

# SYNOPSIS

`test` *command* [ *command-args* ]

# COMMANDS

- `Args1`

  args1 description

---

# NAME

`test` `Args1` - args1 description

# SYNOPSIS

`test` `Args1` [ `-groups` *groups* ] [ `-long` *l* ] [ `-debug` ] [
`-bigdecimal` *bigd* ] [ { `-log` | `-verbose` } *verbose* ] [ `-date` *date* ]
[ `-double` *doub* ] [ `-float` *floa* ] [ `--` ] [ *parameters* ]

# OPTIONS

- `-bigdecimal` *bigd*

  A BigDecimal number

- `-date` *date*

  An ISO 8601 formatted date.

- `-debug`

  Debug mode

- `-double` *doub*

  A double number

- `-float` *floa*

  A float number

- `-groups` *groups*

  Comma-separated list of group names to be run

- `-log` *verbose* , `-verbose` *verbose*

  Level of verbosity

- `-long` *l*

  A long number

- `--`

  This option can be used to separate command-line options from the list of
  arguments (useful when arguments might be mistaken for command-line options)

- *parameters*



# USER DEFINED ALIASES

This CLI supports user defined aliases which may be placed in a test.config file
located in the following location(s):

1. `target/`


This file contains aliases defined in Java properties file style e.g.

    b.foo=bar --flag

Here an alias foo is defined which causes the bar command to be invoked with the
`--flag` option passed to it. Aliases are distinguished from other properties in
the file by the prefix `b.` as seen in the example.

Alias definitions are subject to the following conditions:

  - Aliases cannot override existing commands
  - Aliases cannot be defined in terms of other aliases
] but found [# NAME

`test` -

# SYNOPSIS

`test` *command* [ *command-args* ]

# COMMANDS

- `Args1`

  args1 description

---

# NAME

`test` `Args1` - args1 description

# SYNOPSIS

`test` `Args1` [ `-double` *doub* ] [ `-date` *date* ] [ { `-log` | `-verbose` }
*verbose* ] [ `-long` *l* ] [ `-float` *floa* ] [ `-bigdecimal` *bigd* ] [
`-groups` *groups* ] [ `-debug` ] [ `--` ] [ *parameters* ]

# OPTIONS

- `-bigdecimal` *bigd*

  A BigDecimal number

- `-date` *date*

  An ISO 8601 formatted date.

- `-debug`

  Debug mode

- `-double` *doub*

  A double number

- `-float` *floa*

  A float number

- `-groups` *groups*

  Comma-separated list of group names to be run

- `-log` *verbose* , `-verbose` *verbose*

  Level of verbosity

- `-long` *l*

  A long number

- `--`

  This option can be used to separate command-line options from the list of
  arguments (useful when arguments might be mistaken for command-line options)

- *parameters*



# USER DEFINED ALIASES

This CLI supports user defined aliases which may be placed in a test.config file
located in the following location(s):

1. `target/`


This file contains aliases defined in Java properties file style e.g.

    b.foo=bar --flag

Here an alias foo is defined which causes the bar command to be invoked with the
`--flag` option passed to it. Aliases are distinguished from other properties in
the file by the prefix `b.` as seen in the example.

Alias definitions are subject to the following conditions:

  - Aliases cannot override existing commands
  - Aliases cannot be defined in terms of other aliases
]
        at org.testng.Assert.fail(Assert.java:94)
        at org.testng.Assert.failNotEquals(Assert.java:494)
        at org.testng.Assert.assertEquals(Assert.java:123)
        at org.testng.Assert.assertEquals(Assert.java:176)
        at org.testng.Assert.assertEquals(Assert.java:186)
        at com.github.rvesse.airline.help.markdown.TestHelpMarkdown.user_aliases_help_markdown(TestHelpMarkdown.java:582)


Results :

Failed tests: 
  TestHelpMarkdown.user_aliases_help_markdown:582 expected [# NAME

`test` -

# SYNOPSIS

`test` *command* [ *command-args* ]

# COMMANDS

- `Args1`

  args1 description

---

# NAME

`test` `Args1` - args1 description

# SYNOPSIS

`test` `Args1` [ `-groups` *groups* ] [ `-long` *l* ] [ `-debug` ] [
`-bigdecimal` *bigd* ] [ { `-log` | `-verbose` } *verbose* ] [ `-date` *date* ]
[ `-double` *doub* ] [ `-float` *floa* ] [ `--` ] [ *parameters* ]

# OPTIONS

- `-bigdecimal` *bigd*

  A BigDecimal number

- `-date` *date*

  An ISO 8601 formatted date.

- `-debug`

  Debug mode

- `-double` *doub*

  A double number

- `-float` *floa*

  A float number

- `-groups` *groups*

  Comma-separated list of group names to be run

- `-log` *verbose* , `-verbose` *verbose*

  Level of verbosity

- `-long` *l*

  A long number

- `--`

  This option can be used to separate command-line options from the list of
  arguments (useful when arguments might be mistaken for command-line options)

- *parameters*



# USER DEFINED ALIASES

This CLI supports user defined aliases which may be placed in a test.config file
located in the following location(s):

1. `target/`


This file contains aliases defined in Java properties file style e.g.

    b.foo=bar --flag

Here an alias foo is defined which causes the bar command to be invoked with the
`--flag` option passed to it. Aliases are distinguished from other properties in
the file by the prefix `b.` as seen in the example.

Alias definitions are subject to the following conditions:

  - Aliases cannot override existing commands
  - Aliases cannot be defined in terms of other aliases
] but found [# NAME

`test` -

# SYNOPSIS

`test` *command* [ *command-args* ]

# COMMANDS

- `Args1`

  args1 description

---

# NAME

`test` `Args1` - args1 description

# SYNOPSIS

`test` `Args1` [ `-double` *doub* ] [ `-date` *date* ] [ { `-log` | `-verbose` }
*verbose* ] [ `-long` *l* ] [ `-float` *floa* ] [ `-bigdecimal` *bigd* ] [
`-groups` *groups* ] [ `-debug` ] [ `--` ] [ *parameters* ]

# OPTIONS

- `-bigdecimal` *bigd*

  A BigDecimal number

- `-date` *date*

  An ISO 8601 formatted date.

- `-debug`

  Debug mode

- `-double` *doub*

  A double number

- `-float` *floa*

  A float number

- `-groups` *groups*

  Comma-separated list of group names to be run

- `-log` *verbose* , `-verbose` *verbose*

  Level of verbosity

- `-long` *l*

  A long number

- `--`

  This option can be used to separate command-line options from the list of
  arguments (useful when arguments might be mistaken for command-line options)

- *parameters*



# USER DEFINED ALIASES

This CLI supports user defined aliases which may be placed in a test.config file
located in the following location(s):

1. `target/`


This file contains aliases defined in Java properties file style e.g.

    b.foo=bar --flag

Here an alias foo is defined which causes the bar command to be invoked with the
`--flag` option passed to it. Aliases are distinguished from other properties in
the file by the prefix `b.` as seen in the example.

Alias definitions are subject to the following conditions:

  - Aliases cannot override existing commands
  - Aliases cannot be defined in terms of other aliases
]

environment:
Apache Maven 3.3.3 (NON-CANONICAL_2015-07-10T12:37:52_mockbuild; 2015-07-10T14:37:52+02:00)
Maven home: /usr/share/maven
Java version: 1.8.0_65, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-13.b17.fc23.i386/jre
Default locale: it_IT, platform encoding: UTF-8
OS name: "linux", version: "4.2.7-300.fc23.i686", arch: "i386", family: "unix"

Any ideas as to why?

Support ServiceLoader for dynamically loading factories for restrictions and help sections

Currently adding new restriction factories and help section factories requires manual registration of these things in code. It would be nice to automatically discover these via a ServiceLoader based mechanism.

This will require some changes:

  • Factory classes will need to declare the class or classes they support so the registries can map them appropriately
  • Need to add appropriate resource files with built-ins added

Support Markdown format help generation

Currently we support RONN help generation which is an extension to Markdown but which unfortunately is broken in some key ways (mainly around nested lists). Hence it will be replaced with direct man page generation in the near future (#29)

It would be nice to support more direct plain Markdown generation

Bash completion for groups is broken

There are a number of bugs in the script functions generated for completing groups which render the whole completion script invalid for CLIs that use groups

  • case has no corresponding esac to terminate it
  • Various new lines are missing making the output unreadable

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.