Uploaded image for project: 'Commons CLI'
  1. Commons CLI
  2. CLI-154

Incomplete usage documentation about Java property option

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0, 1.1
    • Fix Version/s: 1.2
    • Component/s: Documentation
    • Labels:
      None

      Description

      On Usage Scenarios page http://jakarta.apache.org/commons/cli/usage.html, in the "Java property option" section of "Ant example", after the creation of the property Option, ie :

      Option property = OptionBuilder.withArgName( "property=value" )
      .hasArg()
      .withValueSeparator()
      .withDescription( "use value for given property" )
      .create( "D" );

      One should add :

      property.setArgs(Option.UNLIMITED_VALUES);

      for the example to work properly.

      In the "Querying the commandline" section, the code line :
      this.buildfile = line.getValue( "buildfile" );

      should be :
      this.buildfile = line.getOptionValue( "buildfile" );

      Also some parsing code could be given about the special property option, for instance :

      Properties props = new Properties();

      if( line.hasOption( "D" ) ) {

      String[] args = line.getOptionValues( "D" );

      for (int i = 0; i < args.length; i += 2)

      { String propertyName = args[i]; String propertyValue = null; if (i + 1 < args.length) propertyValue = args[i + 1]; props.put(propertyName, propertyValue); }

      }

        Activity

        Hide
        ebourg Emmanuel Bourg added a comment -

        Method added and documented.

        Show
        ebourg Emmanuel Bourg added a comment - Method added and documented.
        Hide
        ebourg Emmanuel Bourg added a comment -

        Now that CLI-137 is fixed I changed the doc to use hasArgs(2) instead of hasArgs(), otherwise the -D option collects the remaning arguments (for example with -Dfoo=bar myapp.jar, the option would receive the jar as its 3rd value)

        Regarding the parsing of the properties, the current API is clearly inconvenient. The CommandLine class should provide a method to access them easily, something like:

        Properties props = cmdline.getOptionProperties("D");
        String value = props.get("foo");
        
        Show
        ebourg Emmanuel Bourg added a comment - Now that CLI-137 is fixed I changed the doc to use hasArgs(2) instead of hasArgs(), otherwise the -D option collects the remaning arguments (for example with -Dfoo=bar myapp.jar, the option would receive the jar as its 3rd value) Regarding the parsing of the properties, the current API is clearly inconvenient. The CommandLine class should provide a method to access them easily, something like: Properties props = cmdline.getOptionProperties( "D" ); String value = props.get( "foo" );
        Hide
        bayard Henri Yandell added a comment -

        The hasArg->hasArgs change has been made.

        Show
        bayard Henri Yandell added a comment - The hasArg->hasArgs change has been made.
        Hide
        haution HAUTION Philippe added a comment -

        Yes, you are right, using Option.hasArgs() instead of Option.hasArg() is a simpler solution to the first issue than doing a .setArgs(Option.UNLIMITED_VALUES).

        Show
        haution HAUTION Philippe added a comment - Yes, you are right, using Option.hasArgs() instead of Option.hasArg() is a simpler solution to the first issue than doing a .setArgs(Option.UNLIMITED_VALUES).
        Hide
        bayard Henri Yandell added a comment -

        Additionally, looks like the solution to the first is to have .hasArgs() rather than .hasArg()

        Show
        bayard Henri Yandell added a comment - Additionally, looks like the solution to the first is to have .hasArgs() rather than .hasArg()
        Hide
        bayard Henri Yandell added a comment -

        The first one appears to be a result of the change from unlimited to one value reported in CLI-137. Change will depend on the resolution to that issue.

        I've fixed the second one.

        Haven't looked at the third one yet.

        Show
        bayard Henri Yandell added a comment - The first one appears to be a result of the change from unlimited to one value reported in CLI-137 . Change will depend on the resolution to that issue. I've fixed the second one. Haven't looked at the third one yet.

          People

          • Assignee:
            Unassigned
            Reporter:
            haution HAUTION Philippe
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1h
              1h
              Remaining:
              Remaining Estimate - 1h
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development