Hi Claude,
I just did after seeing your message, instead of going round and round ;)
Gary
On 2024/10/19 10:22:28 Claude Warren wrote:
> Gary,
>
> I went looking for the javadoc in question but did not find it. Did you
> already clean it up? If so, thanks. If not can you point to the issue?
>
Gary,
I went looking for the javadoc in question but did not find it. Did you
already clean it up? If so, thanks. If not can you point to the issue?
Thank you,
Claude
On Thu, Oct 17, 2024 at 3:08 PM Gary D. Gregory wrote:
> Note that the Javadoc for org.apache.commons.cli.help.HelpFormatter
Note that the Javadoc for org.apache.commons.cli.help.HelpFormatter use
deprecated code. Please update it or I can do it later.
Gary
On 2024/10/17 13:39:53 Claude Warren wrote:
> I think that all of the HelpAppendable methods expect that if null or empty
> string is passed then nothing is output
I think that all of the HelpAppendable methods expect that if null or empty
string is passed then nothing is output. In addition, for the list case an
empty list results in no output.
I will update the documentation.
On Thu, Oct 17, 2024 at 10:20 AM Arnout Engelen wrote:
> On Mon, Oct 14, 2024
On Mon, Oct 14, 2024 at 9:29 PM Gary D. Gregory wrote:
>
> Hi All,
>
> We now have append methods like:
>
> public interface HelpAppendable extends Appendable {
>
> /**
> * Appends a header.
> *
> * @param level the level of the header. This is equivalent to the "1",
> "2", or
Let's get back on topic here please: What I'm looking for is what the
JAVADOC should say, in words, to set expectations for users/call sites and
provide guidance for implementors.
What matters more is what null means when it's allowed because telling me
something is nullable with an annotation is
On Wed, 16 Oct 2024 at 16:15, Gary Gregory wrote:
>
> I don't think we need this, mostly because I prefer to not have issues with
> annotation X vs. Y vs. Z. There are a ton of these types of annotations out
> there and using one vs another because the Jetbrain IDE likes it is not a
> good enough
We had a discussion about the same thing a few month ago - I personally
like this kind of annotations a lot. I found a very interesting project
at https://jspecify.dev/
A good overview mentioning several implementations at
https://stackoverflow.com/questions/4963300/which-notnull-java-annotati
I don't think we need this, mostly because I prefer to not have issues with
annotation X vs. Y vs. Z. There are a ton of these types of annotations out
there and using one vs another because the Jetbrain IDE likes it is not a
good enough reason IMO. There's also a javax version, and a jakarta
vers
Yeah, it was the dependency question. I know that in general commons
projects try to keep dependencies to a minimum. I like the idea and think
I would agree with you after playing with the annotations.
On Wed, Oct 16, 2024 at 3:17 PM Xeno Amess wrote:
> apply jsr 305 annotations just make code
apply jsr 305 annotations just make codes neat (IMO)
also good for quite some ide/analyzing tools when they try index/auto find
bugs.
well there be very many jsr-305 impls so if not jetbrains we can use google
code or even impl our own one.
negative point is we need another dependency(though usuall
What is the general stance on commons to import the annotations? Is there
a reason not to? I'm happy to make the changes but want to make sure there
is not a blocker first.
Claude
On Tue, Oct 15, 2024 at 9:56 AM Xeno Amess wrote:
> yep, I always think, this kind of allow null not allow null t
yep, I always think, this kind of allow null not allow null things shall be
marked not by doc, but by annotations.
Xeno Amess 于2024年10月15日周二 04:10写道：
> 1. important jetbrains annotations as maven dependency.
> 2.add @Nullable in parent class's param
> 3.add @NotNull at child class param
>
>
1. important jetbrains annotations as maven dependency.
2.add @Nullable in parent class's param
3.add @NotNull at child class param
From: Gary D. Gregory
Sent: Tuesday, October 15, 2024 3:29:20 AM
To: dev@commons.apache.org
Subject: [CLI] Javadoc
Hi All,
We now
14 matches
Mail list logo
