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
