Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parsing problem after ParserRules#OPTION_TERMINATOR if enum argument is present #1

Open
chreex opened this issue Mar 25, 2015 · 1 comment
Labels

Comments

@chreex
Copy link

chreex commented Mar 25, 2015

If an enum argument is present, for example in the form '--enumMappedCmdlineOption ENUM_VALUE --anythingElse1 --anythingElse2 -- --nonOptionArg1 --nonOptionArg2', the textual form of ENUM_VALUE will be the first element after the '--' option terminator returned by AnnotatedClass#nonOptionArguments().

Workaround is using '=' character to separate the enum mapped command line option and its value:

--enumMappedCmdlineOption=ENUM_VALUE
@chreex chreex added the bug label Mar 25, 2015
@pulinyul
Copy link

pulinyul commented Apr 3, 2015

I could reproduce this by supplying a boolean argument without value declaration before the enum argument, like this:
--booleanArg1 --enumMappedCmdlineOption ENUM_VALUE

The problem seems strongly related to JOSimpleBoolean annotated fields: it seems, that writing anything else after such a --booleanArg1 is treated by the parser as the value declaration for booleanArg1. As a result, in the above example, the boolean value remains false, and the String afterwars is "swallowed" by the parser, and therefore the the enum remains at its default value, discarding the value on the command line

Writing booleanArg1=true works around the problem, and the enum (and the boolean) get their correct value even if no = sign is used for the enum.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants