[rfc][icedtea-web] Option Parser

[Lukasz Dracz]

Hello,

> >
> > -            String key = props[i].substring(0, equals);
> > -            String value = props[i].substring(equals + 1,
> > props[i].length());
> > +            String key = input.split("=")[0];
> > +            String value = input.split("=")[1];
> 
> 
> Unluckily the behaviour changed here.  What if vale contains equals chat to?
> 
> Please keep prevoius indexOf approach:(

Okay, changed back to indexOf approach


> > -        ParserSettings settings =
> > ParserSettings.setGlobalParserSettingsFromArgs(args);
> > +        ParserSettings settings = new
> > ParserSettings(optionParser.hasOption(OptionsDefinitions.OPTIONS.STRICT),
> > true, !optionParser.hasOption(OptionsDefinitions.OPTIONS.XML));
> > +        ParserSettings.setGlobalParserSettings(settings);
> 
> Please hide those two lines.

Okay

> add
> public whatever setGlobalParserSettingsFromOptionParser(Optionparser
> optionParser){
>   ParserSettings settings = new
> ParserSettings(optionParser.hasOption(OptionsDefinitions.OPTIONS.STRICT),
> true,
> !optionParser.hasOption(OptionsDefinitions.OPTIONS.XML));
> this.setGlobalParserSettings(settings);
> 
> }
> 
> in ParserSettings
> 
> and here call setGlobalParserSettingsFromOptionParser(optionParser)
> only
> 
> Consequentially return (modified) the rmeoved test.

Test is back and added one more test as well. 

> 
> If you fulfill all nits above, please add also chnagelog in next iteration. I
> believe it will be
> last one.. Otherwise we both grow old and turn gray before it is finish.

Okay added the ChangeLog. 
Also I reworked findMainArg method, before it would choose the first value without a dash from the last args, which does not make sense now that we accept arguments with/without dashes. Now it checks for the last value that is not an option or does not have an option right before it that takes OneArgument / OneOrMoreArguments. My reasoning for this is if you have for ex. 'command -arg green blue File.jnlp -update 25' we know update only takes one argument so we know
25 is not the user's main argument but File.jnlp is since blue is not an option. Also for ex. 'command -arg green blue File.jnlp -arg yellow' I figured we know arg takes one or more arguments but if it has exactly one argument then it is
intentional by the user so in this case File.jnlp is found as the main arg instead of yellow. However if the user does 'command -arg green blue File.jnlp -arg yellow red' then the parser will use red as the main argument which I think is okay and the user should specify in this case either by putting File.jnlp after red or -jnlp infront of File.jnlp.

Also added four unit tests to OptionParserTest to make sure this is working as intended.

> Also remember, your next task is to port ITWsettings and polieditor to use
> this class.

Yes, I have been looking at how ITWsettings does its parsing and will probably tackle this one next and PolicyEditor after.

> Looking forward to have this in!
>    J.
> 

Thank you,
Lukasz Dracz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: optionParser-20.patch
Type: text/x-patch
Size: 52598 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140915/259fef3b/optionParser-20-0001.patch>