Re: [CLI] Javadoc

[Arnout Engelen]

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 "3" in the HTML "h1", "h2", "h3" tags.
>  * @param text  the text for the header
>  * @throws IOException on write failure
>  */
> void appendHeader(int level, CharSequence text) throws IOException;
>
> ...
>
> The supertype defines behavior for null input, but here we do not, we should 
> either document it as:
> - Same as the super type, same kind of Javadoc
> - Explicitly document that it is up to the implementing class
>
> Thoughts?

While for the general 'append' I can see the motivation for outputting
'null' for null input. For headers it seems simply invalid to me, and
IMO it'd make more sense to declare all implementations should throw a
NullPointerException in that case.

If we do decide to allow null here, I think we should define the
behavior in a way that all implementations can follow - which the
super type does nicely ('If csq is null, then characters will be
appended as if csq contained the four characters "null".'). I don't
see a strong reason to leave it up to the implementing class - what
would be the use case?


Kind regards,

-- 
Arnout Engelen
ASF Security Response
Apache Pekko PMC member, ASF Member
NixOS Committer
Independent Open Source consultant

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

Re: [CLI] Javadoc

[Claude Warren]

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 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 "3" in the HTML "h1", "h2", "h3" tags.
> >  * @param text  the text for the header
> >  * @throws IOException on write failure
> >  */
> > void appendHeader(int level, CharSequence text) throws IOException;
> >
> > ...
> >
> > The supertype defines behavior for null input, but here we do not, we
> should either document it as:
> > - Same as the super type, same kind of Javadoc
> > - Explicitly document that it is up to the implementing class
> >
> > Thoughts?
>
> While for the general 'append' I can see the motivation for outputting
> 'null' for null input. For headers it seems simply invalid to me, and
> IMO it'd make more sense to declare all implementations should throw a
> NullPointerException in that case.
>
> If we do decide to allow null here, I think we should define the
> behavior in a way that all implementations can follow - which the
> super type does nicely ('If csq is null, then characters will be
> appended as if csq contained the four characters "null".'). I don't
> see a strong reason to leave it up to the implementing class - what
> would be the use case?
>
>
> Kind regards,
>
> --
> Arnout Engelen
> ASF Security Response
> Apache Pekko PMC member, ASF Member
> NixOS Committer
> Independent Open Source consultant
>
> -
> 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] Javadoc

[Gary D. Gregory]

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.  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 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 "3" in the HTML "h1", "h2", "h3" tags.
> > >  * @param text  the text for the header
> > >  * @throws IOException on write failure
> > >  */
> > > void appendHeader(int level, CharSequence text) throws IOException;
> > >
> > > ...
> > >
> > > The supertype defines behavior for null input, but here we do not, we
> > should either document it as:
> > > - Same as the super type, same kind of Javadoc
> > > - Explicitly document that it is up to the implementing class
> > >
> > > Thoughts?
> >
> > While for the general 'append' I can see the motivation for outputting
> > 'null' for null input. For headers it seems simply invalid to me, and
> > IMO it'd make more sense to declare all implementations should throw a
> > NullPointerException in that case.
> >
> > If we do decide to allow null here, I think we should define the
> > behavior in a way that all implementations can follow - which the
> > super type does nicely ('If csq is null, then characters will be
> > appended as if csq contained the four characters "null".'). I don't
> > see a strong reason to leave it up to the implementing class - what
> > would be the use case?
> >
> >
> > Kind regards,
> >
> > --
> > Arnout Engelen
> > ASF Security Response
> > Apache Pekko PMC member, ASF Member
> > NixOS Committer
> > Independent Open Source consultant
> >
> > -
> > 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: [EXEC][POLL] Raising the Java platform from Java 8 to 11 EXEC-123

[Siegfried Goeschl]

+1 fo JDK 11 

Thanks in advance, 

Siegfried Goeschl


> On 17.10.2024, at 18:52, Gary Gregory  wrote:
> 
> Hi All:
> 
> To support https://issues.apache.org/jira/browse/EXEC-123, it would be best
> to raise the Java platform from Java 8 to 11.
> 
> WDYT?
> 
> Gary


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

[EXEC][POLL] Raising the Java platform from Java 8 to 11 EXEC-123

[Gary Gregory]

Hi All:

To support https://issues.apache.org/jira/browse/EXEC-123, it would be best
to raise the Java platform from Java 8 to 11.

WDYT?

Gary

Re: [EXEC][POLL] Raising the Java platform from Java 8 to 11 EXEC-123

[Eric Pugh]

+1.   

> On Oct 17, 2024, at 1:19 PM, Xeno Amess  wrote:
> 
> +1 for 11
> even better if 17
> 
> From: Gary Gregory 
> Sent: Friday, October 18, 2024 12:52:38 AM
> To: Commons Developers List 
> Subject: [EXEC][POLL] Raising the Java platform from Java 8 to 11 EXEC-123
> 
> Hi All:
> 
> To support https://issues.apache.org/jira/browse/EXEC-123, it would be best
> to raise the Java platform from Java 8 to 11.
> 
> WDYT?
> 
> Gary

___
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: [EXEC][POLL] Raising the Java platform from Java 8 to 11 EXEC-123

[Xeno Amess]

+1 for 11
even better if 17

From: Gary Gregory 
Sent: Friday, October 18, 2024 12:52:38 AM
To: Commons Developers List 
Subject: [EXEC][POLL] Raising the Java platform from Java 8 to 11 EXEC-123

Hi All:

To support https://issues.apache.org/jira/browse/EXEC-123, it would be best
to raise the Java platform from Java 8 to 11.

WDYT?

Gary

[VOTE] Release Apache Commons Parent 78 based on RC1

[Gary Gregory]

We have fixed a few bugs and added enhancements since Apache Commons Parent
77 was released, so I would like to release Apache Commons Parent 78.

Apache Commons Parent 78 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/parent/78-RC1 (svn
revision 72392)

The Git tag commons-parent-78-RC1 commit for this RC is
b80d7d69e9f9d53b18e39aa83833ee5c1cd8ba5a which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=b80d7d69e9f9d53b18e39aa83833ee5c1cd8ba5a
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-parent.git
--branch commons-parent-78-RC1 commons-parent-78-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1783/org/apache/commons/commons-parent/78/

These are the artifacts and their hashes:

#Release SHA-512s
#Thu Oct 17 17:38:46 UTC 2024
commons-parent-78-bom.json=c35af7728b3bebbe26b9b09d33574e518136cee613dfdab0a2d01e5e7493bd18215efebc61f9375018e78f6f3338e407b3330412be386a4aa4a93484da6ff80a
commons-parent-78-bom.xml=20d7a3f8853c951e33d5f945e1f5da7b1338fac6c400b72a8fb67119db10c69027ff7a1a82189e69359695931e956963dc4650f2500a46b11ef7f8e0f7a9d427
commons-parent-78-site.xml=67d93a8bd57621ef1ff9b3576e8708fe2e95a9e33ca3c37959dec286ebb14f518a987d4e20d72e4bc595bf7a623794c864ffca3202dfe02c227caad37b5a7bd8
commons-parent-78-src.tar.gz=dc954e21c73a0b5cccda0c9a2a4a94db28269dbcc67d1625fc257ff28c45705c35cd2e6c3ec56f257035e1b18acd4ef545274bef147529aa41e381ddd2efee99
commons-parent-78-src.zip=57e0e4cbaf5086542ae5dfbd7a58497e3d2c6d86d11606c69d545238c33519c5445e648fdfc3ff9781a9daec9a771aeeb6591e4d10e837b8d04729ad2b7277d3
org.apache.commons_commons-parent-78.spdx.json=f2c7d9f2d66584e9dae533dfdefb15b7c257faad0988cc5e420addfdff11db36304031babeb1ab2dcddfdb0c4f2524eeca0452c2948cdf3d845137850c16ee92



I have tested this with ***'mvn clean install site'*** using:
***
Use the output from "mvn -version" for each combination you tested.
Windows: ver
Linux: uname -a
***

Details of changes since 77 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/parent/78-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/parent/78-RC1/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/parent/78-RC1/site/index.html
(note some *relative* links are broken and the 78 directories are not
yet created - these will be OK once the site is deployed.)

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/parent/78-RC1/site/rat-report.html

KEYS:
  https://downloads.apache.org/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)

The following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1a) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch
commons-parent-78-RC1 commons-parent-78-RC1
cd commons-parent-78-RC1

1b) Download and unpack the source archive from:

https://dist.apache.org/repos/dist/dev/commons/parent/78-RC1/source

2) Check Apache licenses

This step is not required if the site includes a RAT report page which you
then must check.

mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page which
you then must check.

mvn clirr:check

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the site includes a JApiCmp report page which
you then must check.

mvn install -DskipTests -P japicmp japicmp:cmp

4) Build the package

mvn -V clean package

You can record the Maven and Java version produced by -V in your VOTE reply.
To gather OS information from a command line:
Windows: ver
Linux: uname -a

5) Build the site for a single module project

Note: Some plugins require the components to be installed instead of
packaged.

mvn site
Check the site reports in:
- Windows: target\site\index.html
- Linux: target/site/index.html

-the end-