Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

Gary,

I just realized this AM that there is a change I proposed to simplify the
deprecated output.  Please see pull request 277.  I think the change from
BiFormat to Format makes the HelpFormatter API much cleaner.

Claude


On Fri, May 17, 2024 at 6:26 PM Claude Warren  wrote:

> Gary,
>
> I think the CLI release candidate can be cut now.  I didn't see any more
> issues when I was fixing the code.  So I am
> +1 on cutting a release candidate.
>
> On Sun, May 12, 2024 at 8:49 PM Gary Gregory 
> 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  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 
>> 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

Re: [CLI] Deprecated options and helpformatting

[Gary Gregory]

The RC is out.

Gary

On Fri, May 17, 2024 at 12:27 PM Claude Warren  wrote:
>
> Gary,
>
> I think the CLI release candidate can be cut now.  I didn't see any more
> issues when I was fixing the code.  So I am
> +1 on cutting a release candidate.
>
> On Sun, May 12, 2024 at 8:49 PM Gary Gregory  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  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 
> > 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

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

Gary,

I think the CLI release candidate can be cut now.  I didn't see any more
issues when I was fixing the code.  So I am
+1 on cutting a release candidate.

On Sun, May 12, 2024 at 8:49 PM Gary Gregory  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  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 
> 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

Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

At one point i suggested a set of helper functions for Option.  I think
that it would really help before this change goes out.  With it we can
reasonably change the BiFunction to a simple function taking an Option and
returning a String.

I will code this up tomorrow.

Claude

On Wed 15 May 2024, 09:14 Claude Warren,  wrote:

> I opened CLI-333 to address the Build production method issue.
>
> On Tue, May 14, 2024 at 10:25 PM Gary Gregory 
> wrote:
>
>> Sounds good to me! Thank you for talking it out. GoF reference appreciated
>> 👏  😉
>>
>> Looking forward to a PR,
>> Gary
>>
>> On Tue, May 14, 2024, 1:47 PM Claude Warren  wrote:
>>
>> > I have to admit that i am partial to build but in reviewing gang of four
>> > and various java build patterns i find that there are a number of
>> terminal
>> > methods.
>> >
>> > Gary is, I now believe, correct; that the builder should implement
>> > Supplier.
>> >
>> >
>> >
>> > On Tue 14 May 2024, 19:28 Claude Warren,  wrote:
>> >
>> > > By factory i assume you mean builder in this context
>> > >
>> > > To my understanding a factory can produce mutiple types of objects
>> while
>> > a
>> > > builder ony one.  I got called out on that awhile ago on a different
>> > project
>> > >
>> > > Should we then make all existing builders in CLI implement supplier
>> and
>> > > deprecate the current build methods in favor of get?  Would this be
>> your
>> > > recommendation?
>> > >
>> > >
>> > >
>> > > On Tue 14 May 2024, 19:02 Gary Gregory, 
>> wrote:
>> > >
>> > >> Also think of the anti pattern of all Commons Components implementing
>> > >> their
>> > >> own factory pattern with a custom interface instead of just reusing
>> > Java's
>> > >> own Supplier.
>> > >>
>> > >> Gary
>> > >>
>> > >> On Tue, May 14, 2024, 1:00 PM Gary Gregory 
>> > >> wrote:
>> > >>
>> > >> > IMO future factories should only be Suppliers.
>> > >> >
>> > >> > Whether to deprecate current code in favor of Suppliers is
>> possible if
>> > >> > only a bit noisy.
>> > >> >
>> > >> > Gary
>> > >> >
>> > >> > On Tue, May 14, 2024, 12:22 PM Claude Warren 
>> > wrote:
>> > >> >
>> > >> >> 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 
>> > >> 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 > >
>> > >> 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:
>> > >> >>  >
>> >

Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

I opened CLI-333 to address the Build production method issue.

On Tue, May 14, 2024 at 10:25 PM Gary Gregory 
wrote:

> Sounds good to me! Thank you for talking it out. GoF reference appreciated
> 👏  😉
>
> Looking forward to a PR,
> Gary
>
> On Tue, May 14, 2024, 1:47 PM Claude Warren  wrote:
>
> > I have to admit that i am partial to build but in reviewing gang of four
> > and various java build patterns i find that there are a number of
> terminal
> > methods.
> >
> > Gary is, I now believe, correct; that the builder should implement
> > Supplier.
> >
> >
> >
> > On Tue 14 May 2024, 19:28 Claude Warren,  wrote:
> >
> > > By factory i assume you mean builder in this context
> > >
> > > To my understanding a factory can produce mutiple types of objects
> while
> > a
> > > builder ony one.  I got called out on that awhile ago on a different
> > project
> > >
> > > Should we then make all existing builders in CLI implement supplier and
> > > deprecate the current build methods in favor of get?  Would this be
> your
> > > recommendation?
> > >
> > >
> > >
> > > On Tue 14 May 2024, 19:02 Gary Gregory, 
> wrote:
> > >
> > >> Also think of the anti pattern of all Commons Components implementing
> > >> their
> > >> own factory pattern with a custom interface instead of just reusing
> > Java's
> > >> own Supplier.
> > >>
> > >> Gary
> > >>
> > >> On Tue, May 14, 2024, 1:00 PM Gary Gregory 
> > >> wrote:
> > >>
> > >> > IMO future factories should only be Suppliers.
> > >> >
> > >> > Whether to deprecate current code in favor of Suppliers is possible
> if
> > >> > only a bit noisy.
> > >> >
> > >> > Gary
> > >> >
> > >> > On Tue, May 14, 2024, 12:22 PM Claude Warren 
> > wrote:
> > >> >
> > >> >> 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 
> > >> 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 
> > >> 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  >
> > >> >> 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
> >

Re: [CLI] Deprecated options and helpformatting

[Gary Gregory]

Sounds good to me! Thank you for talking it out. GoF reference appreciated
👏  😉

Looking forward to a PR,
Gary

On Tue, May 14, 2024, 1:47 PM Claude Warren  wrote:

> I have to admit that i am partial to build but in reviewing gang of four
> and various java build patterns i find that there are a number of terminal
> methods.
>
> Gary is, I now believe, correct; that the builder should implement
> Supplier.
>
>
>
> On Tue 14 May 2024, 19:28 Claude Warren,  wrote:
>
> > By factory i assume you mean builder in this context
> >
> > To my understanding a factory can produce mutiple types of objects while
> a
> > builder ony one.  I got called out on that awhile ago on a different
> project
> >
> > Should we then make all existing builders in CLI implement supplier and
> > deprecate the current build methods in favor of get?  Would this be your
> > recommendation?
> >
> >
> >
> > On Tue 14 May 2024, 19:02 Gary Gregory,  wrote:
> >
> >> Also think of the anti pattern of all Commons Components implementing
> >> their
> >> own factory pattern with a custom interface instead of just reusing
> Java's
> >> own Supplier.
> >>
> >> Gary
> >>
> >> On Tue, May 14, 2024, 1:00 PM Gary Gregory 
> >> wrote:
> >>
> >> > IMO future factories should only be Suppliers.
> >> >
> >> > Whether to deprecate current code in favor of Suppliers is possible if
> >> > only a bit noisy.
> >> >
> >> > Gary
> >> >
> >> > On Tue, May 14, 2024, 12:22 PM Claude Warren 
> wrote:
> >> >
> >> >> 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 
> >> 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 
> >> 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 
> >> >> 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  >
> >> >> 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?
> >> >>  > >>
> >> >>  > >> Wo

Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

I have to admit that i am partial to build but in reviewing gang of four
and various java build patterns i find that there are a number of terminal
methods.

Gary is, I now believe, correct; that the builder should implement Supplier.



On Tue 14 May 2024, 19:28 Claude Warren,  wrote:

> By factory i assume you mean builder in this context
>
> To my understanding a factory can produce mutiple types of objects while a
> builder ony one.  I got called out on that awhile ago on a different project
>
> Should we then make all existing builders in CLI implement supplier and
> deprecate the current build methods in favor of get?  Would this be your
> recommendation?
>
>
>
> On Tue 14 May 2024, 19:02 Gary Gregory,  wrote:
>
>> Also think of the anti pattern of all Commons Components implementing
>> their
>> own factory pattern with a custom interface instead of just reusing Java's
>> own Supplier.
>>
>> Gary
>>
>> On Tue, May 14, 2024, 1:00 PM Gary Gregory 
>> wrote:
>>
>> > IMO future factories should only be Suppliers.
>> >
>> > Whether to deprecate current code in favor of Suppliers is possible if
>> > only a bit noisy.
>> >
>> > Gary
>> >
>> > On Tue, May 14, 2024, 12:22 PM Claude Warren  wrote:
>> >
>> >> 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 
>> 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 
>> 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 
>> >> 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 
>> >> 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 

Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

By factory i assume you mean builder in this context

To my understanding a factory can produce mutiple types of objects while a
builder ony one.  I got called out on that awhile ago on a different project

Should we then make all existing builders in CLI implement supplier and
deprecate the current build methods in favor of get?  Would this be your
recommendation?



On Tue 14 May 2024, 19:02 Gary Gregory,  wrote:

> Also think of the anti pattern of all Commons Components implementing their
> own factory pattern with a custom interface instead of just reusing Java's
> own Supplier.
>
> Gary
>
> On Tue, May 14, 2024, 1:00 PM Gary Gregory  wrote:
>
> > IMO future factories should only be Suppliers.
> >
> > Whether to deprecate current code in favor of Suppliers is possible if
> > only a bit noisy.
> >
> > Gary
> >
> > On Tue, May 14, 2024, 12:22 PM Claude Warren  wrote:
> >
> >> 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  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 
> 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 
> >> 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 
> >> 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  >
> >>  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
> >>  > >> >

Re: [CLI] Deprecated options and helpformatting

[Gary Gregory]

Also think of the anti pattern of all Commons Components implementing their
own factory pattern with a custom interface instead of just reusing Java's
own Supplier.

Gary

On Tue, May 14, 2024, 1:00 PM Gary Gregory  wrote:

> IMO future factories should only be Suppliers.
>
> Whether to deprecate current code in favor of Suppliers is possible if
> only a bit noisy.
>
> Gary
>
> On Tue, May 14, 2024, 12:22 PM Claude Warren  wrote:
>
>> 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  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  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 
>> 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 
>> >>> 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 
>> 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 
>>  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?
>>  > >> > >
>>  > >> 

Re: [CLI] Deprecated options and helpformatting

[Gary Gregory]

IMO future factories should only be Suppliers.

Whether to deprecate current code in favor of Suppliers is possible if only
a bit noisy.

Gary

On Tue, May 14, 2024, 12:22 PM Claude Warren  wrote:

> 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  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  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  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 
> >>> 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 
> 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 
>  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  >
>  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

Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

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  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  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  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 
>>> 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  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 
 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 
 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:

Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

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  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  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 
>> 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  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 
>>> wrote:
>>> >
>>> > > Will do.
>>> > >
>>> > > On Sun, May 12, 2024 at 8:49 PM Gary Gregory >> >
>>> > > 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 
>>> 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 >> >
>>> > >> 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

Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

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  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 
> 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  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 
>> wrote:
>> >
>> > > Will do.
>> > >
>> > > On Sun, May 12, 2024 at 8:49 PM Gary Gregory 
>> > > 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 
>> 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 
>> > >> 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

Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

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  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  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  wrote:
> >
> > > Will do.
> > >
> > > On Sun, May 12, 2024 at 8:49 PM Gary Gregory 
> > > 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 
> 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 
> > >> 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

Re: [CLI] Deprecated options and helpformatting

[Gary Gregory]

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  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  wrote:
>
> > Will do.
> >
> > On Sun, May 12, 2024 at 8:49 PM Gary Gregory 
> > 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  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 
> >> 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

Re: [CLI] Deprecated options and helpformatting

[Eric Pugh]

I *thought* that is how things work….  I am going to double check my usage of 
this feature in Solr CLI (not yet released) and report back!

> On May 14, 2024, at 8:25 AM, Claude Warren  wrote:
> 
> I also think that the if an Option is marked with deprecated then the
> HelpFormatter should, by default, inlcude the "[Deprecated]" line. (I am
> working on a  change for this too)
> 
> On Tue, May 14, 2024 at 2:22 PM Claude Warren  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  wrote:
>> 
>>> Will do.
>>> 
>>> On Sun, May 12, 2024 at 8:49 PM Gary Gregory 
>>> 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  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 
 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
>> 
> 
> 
> -- 
> LinkedIn: http://www.linkedin.com/in/claudewarren

___
Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

I also think that the if an Option is marked with deprecated then the
HelpFormatter should, by default, inlcude the "[Deprecated]" line. (I am
working on a  change for this too)

On Tue, May 14, 2024 at 2:22 PM Claude Warren  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  wrote:
>
>> Will do.
>>
>> On Sun, May 12, 2024 at 8:49 PM Gary Gregory 
>> 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  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 
>>> 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
>


-- 
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

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  wrote:

> Will do.
>
> On Sun, May 12, 2024 at 8:49 PM Gary Gregory 
> 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  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 
>> 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

Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

Will do.

On Sun, May 12, 2024 at 8:49 PM Gary Gregory  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  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 
> 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

Re: [CLI] Deprecated options and helpformatting

[Gary Gregory]

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  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  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

Re: [CLI] Deprecated options and helpformatting

[Claude Warren]

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  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
>
>
>