I have submitted a draft pull request https://github.com/apache/commons-cli/pull/272
However, I would like to resolve the Builder/build Builder/get naming issue before I take it out of draft mode. On Tue, May 14, 2024 at 6:05 PM Claude Warren <cla...@xenei.com> wrote: > I will add some tests to show what it is doing in the various cases. But > I think that since we are now providing external developers with the > ability to display custom information about the Option there are a > couple of function that we could probably use internally and provide to the > external developer. > > A prime example is the ability to get the string "-s" or "-s, --longopt" > or "--longopt" as an output based on weather the option has a short option, > long option or both defined. This is used in several places internally, > and I have had to code it for some external code I was developing. > > There are probably others that we can find the code base but I was > thinking an "OptionUtils" or "OptionFormat" or "OptionHelper" class that > has static methods taking an Option. > > Are there any objections to this? > > > On Tue, May 14, 2024 at 4:08 PM Claude Warren <cla...@xenei.com> wrote: > >> Eric, I may have broken it with my implementation of the HelpFormatter >> deprecatedFormatFunc() method. >> >> On Tue, May 14, 2024 at 4:06 PM Claude Warren <cla...@xenei.com> wrote: >> >>> We already have historical uses of builders in CLI (e.g. >>> CommandLine.Builder) that use build() not get(). >>> In addition many of the other commons packages have Builders that are >>> triggered by a "build" call. >>> >>> On Tue, May 14, 2024 at 3:03 PM Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> >>>> Hi All, >>>> >>>> Better documentation is always nice :-) >>>> >>>> I vote for Supplier/get() because it does not require the invention of >>>> something new that does _exactly the same thing as the code already >>>> provided in the JRE_. >>>> >>>> Gary >>>> >>>> On Tue, May 14, 2024 at 8:22 AM Claude Warren <cla...@xenei.com> wrote: >>>> > >>>> > I find a couple of issues: >>>> > >>>> > No documentation for the new options. (I am working on that). >>>> > A weird mix of .get() and .build() methods on builders. The new >>>> builders >>>> > all extend Supplier<> so the get makes sense in that respect, but I >>>> don't >>>> > think this is the normal nomenclature for Builders. I expect a >>>> build() >>>> > method. In any case we should settle on one or the other. In case >>>> it is >>>> > not obvious I vote for build(). >>>> > >>>> > On Mon, May 13, 2024 at 11:54 AM Claude Warren <cla...@xenei.com> >>>> wrote: >>>> > >>>> > > Will do. >>>> > > >>>> > > On Sun, May 12, 2024 at 8:49 PM Gary Gregory < >>>> garydgreg...@gmail.com> >>>> > > wrote: >>>> > > >>>> > >> How does it look now? >>>> > >> >>>> > >> Would you check git master is OK, then I can cut a release >>>> candidate >>>> > >> later in the week. >>>> > >> >>>> > >> Gary >>>> > >> >>>> > >> On Sat, May 11, 2024 at 6:28 AM Claude Warren <cla...@apache.org> >>>> wrote: >>>> > >> > >>>> > >> > Also, it appears that the deprecatedHandler is only tested on >>>> the string >>>> > >> > option processing. if the application retains a list of Options >>>> and >>>> > >> passes >>>> > >> > those in to be checked the deprecation check is not execute. >>>> > >> > >>>> > >> > On Sat, May 11, 2024 at 12:18 PM Claude Warren < >>>> cla...@apache.org> >>>> > >> wrote: >>>> > >> > >>>> > >> > > Greetings, >>>> > >> > > >>>> > >> > > I see that there is a deprecated option in cli 1.7.0, and that >>>> it has >>>> > >> some >>>> > >> > > nice data. But I don't see how to display the info in the >>>> help. >>>> > >> > > >>>> > >> > > It looks like the only option is to print "[Deprecated]" >>>> without any >>>> > >> > > information from the deprecated info. I think the HelpPrinter >>>> needs a >>>> > >> > > function (similar to the command line deprecatedHandler) to >>>> convert >>>> > >> the >>>> > >> > > object to a string that can be prefixed to the option help >>>> output >>>> > >> where the >>>> > >> > > "[Deprecated]" is now. >>>> > >> > > >>>> > >> > > Does this make sense? >>>> > >> > > >>>> > >> > > Is there something I am overlooking that already does this? >>>> > >> > > >>>> > >> > > Claude >>>> > >> > > >>>> > >> > > >>>> > >> > > >>>> > >> >>>> > >> >>>> --------------------------------------------------------------------- >>>> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> > >> For additional commands, e-mail: dev-h...@commons.apache.org >>>> > >> >>>> > >> >>>> > > >>>> > > -- >>>> > > LinkedIn: http://www.linkedin.com/in/claudewarren >>>> > > >>>> > >>>> > >>>> > -- >>>> > LinkedIn: http://www.linkedin.com/in/claudewarren >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> -- >>> LinkedIn: http://www.linkedin.com/in/claudewarren >>> >> >> >> -- >> LinkedIn: http://www.linkedin.com/in/claudewarren >> > > > -- > LinkedIn: http://www.linkedin.com/in/claudewarren > -- LinkedIn: http://www.linkedin.com/in/claudewarren
