[CLI] HelpFormatter final or not?

[Claude Warren]

Greetings,

I am trying to build a new HelpFormatter implementation, however while the
HelpFormatter is not final the HelpFormatter.Builder is.  So I can not
extend the builder to create a new HelpFormatter, All I can do is build the
old one.  Any suggestions for how to get around this problem?

Claude

[CLI] Handling sub commands?

[Eric Pugh]

Hi all,

In Solr-land, we have a set of commands that sub commands that each take 
various options:

Bin/solr zk cp
Bin/solr zk ls
Bin/solr zk rm

Right now we handle picking the right command via the shell (linux) and command 
(windows) scripts.   Is there any interest or way in having commons-cli handle 
figuring out which sub command is being run and calling it?   Or is that beyond 
the remit of what commons-cli does..

For reference, this is where we do our zk logic: 
https://github.com/apache/solr/blob/main/solr/bin/solr#L890 and eventually 
where we pick the command to run: 
https://github.com/apache/solr/blob/main/solr/bin/solr#L1015



Eric
___
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] HelpFormatter final or not?

[Gary Gregory]

Hi Claude,

You can now extend HelpFormatter.Builder in git master and snapshot builds.

Gary

On Sun, Jul 21, 2024 at 4:52 AM Claude Warren  wrote:
>
> Greetings,
>
> I am trying to build a new HelpFormatter implementation, however while the
> HelpFormatter is not final the HelpFormatter.Builder is.  So I can not
> extend the builder to create a new HelpFormatter, All I can do is build the
> old one.  Any suggestions for how to get around this problem?
>
> Claude

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

Re: [CLI] Handling sub commands?

[Gary Gregory]

Are you talking about configuring Commons CLI to run shell commands or
lambdas (where you'd have those run shell commands)?

Gary

On Sun, Jul 21, 2024 at 5:12 AM Eric Pugh
 wrote:
>
> Hi all,
>
> In Solr-land, we have a set of commands that sub commands that each take 
> various options:
>
> Bin/solr zk cp
> Bin/solr zk ls
> Bin/solr zk rm
>
> Right now we handle picking the right command via the shell (linux) and 
> command (windows) scripts.   Is there any interest or way in having 
> commons-cli handle figuring out which sub command is being run and calling 
> it?   Or is that beyond the remit of what commons-cli does..
>
> For reference, this is where we do our zk logic: 
> https://github.com/apache/solr/blob/main/solr/bin/solr#L890 and eventually 
> where we pick the command to run: 
> https://github.com/apache/solr/blob/main/solr/bin/solr#L1015
>
>
>
> Eric
> ___
> 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.
>

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

Re: Issue with escaping CRLF characters with single escape character

[Gary Gregory]

Hello Josh,

Is there a mismatch in expectations of what escaping means?

Escaping works one character at a time: Escape the next single
character. There is no escape start and escape end sequence
characters.

Am I missing something?

Gary

On Wed, Jul 17, 2024 at 5:38 PM Josh Bultman
 wrote:
>
> Hello,
>
> I’m using commons csv for a component in our application, and I ran into a 
> weird edge case. In our application, we take in CSV files from the file 
> system without knowing the format beforehand. So, I’m writing a method that 
> guesses the CSV format based on column consistency, encountering trailing 
> data, and a few other things. While writing tests, I encountered the fact 
> that commons csv does not escape the full CRLF with a single escape 
> character. For example, if \ is the escape character, 
> row,\\r\ntest will be parsed as:
>
> row\r
> test
>
> Instead of:
>
> row,\r\ntest
>
> Initially this felt like the wrong decision to me, so I created a fix for it. 
> During the regression tests, the testRandomMySql test failed because 
> occasionally a \\r was generated as the last part of a row, which 
> also escaped the \n record separator, causing an incorrect number of rows to 
> be read. This made me question whether it’s a good idea at all to escape both 
> the CR and the LF if they’re together, since maybe it’s best to assume that 
> they would be escaped separately like so: \\r\\n. Though, if 
> someone were writing a csv manually on a windows machine and decided to 
> escape a newline, I could see them simply typing \ and then hitting enter, 
> which would give: \\r\n.
>
> I would be interested to hear other people’s thoughts on this. If it’s still 
> something we deem an issue, I can modify the mySQL test and make a PR.
>
> Thank you,
> Josh

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

[LAZY][VOTE] Release Apache Commons Parent 72 based on RC1

[Gary Gregory]

We have added enhancements since Apache Commons Parent 71 was
released, so I would like to release Apache Commons Parent 72.

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

The Git tag commons-parent-72-RC1 commit for this RC is
5eb7ad71ec5db46c9e08527969c00bb3bfced5e3 which you can browse here:

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

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1761/org/apache/commons/commons-parent/72/

These are the artifacts and their hashes:

#Release SHA-512s
#Sun Jul 21 18:25:27 UTC 2024
commons-parent-72-bom.json=7d0abc1bf1aacd58aae935d3f89bb87fc2e5d257470da5033fdd055a5ed11a6422e0db2cbac5103e81099853667c17ac7fc79bc8c5d1103257bc0ae46b6dfb56
commons-parent-72-bom.xml=c51f4b9619b5502fc895ca7b2998dd868115ac16c6547e0a67355160858990f40f4399fd6ef5182cbb6e6d14e65bf91d48da83068a79d1f2808834ce2d89ff22
commons-parent-72-site.xml=5f045989b2c281c567467548678fe8685efabf5c13104299eea87b6ab6b6a75c9e98b590d7b288b8ec3a06934061709d0851a6dd9d9b45100ee2950908ec2d6c
commons-parent-72-src.tar.gz=5c6e0bd4090906fe0dfef5bc204e0de37f2f6177e30a25f1a292734a41954f992e8ee617bfb25c284e96ca0f0d85285f8138721346a6084b023adf99f3b0d752
commons-parent-72-src.zip=2e9811baf549e88a94573fd4239e56180a62971af4bbf3d64f47ba37ea4dddf8d36e9074fd8ed9595172acdb35c0cc107ed5e9474756c6675b1d6bdecc49b558
org.apache.commons_commons-parent-72.spdx.json=6607c088dee95917cf5d06dc51731a6463a6deb66a069f52870d12f3c733b063b142376240829d9afc3356f430d17ba6b8f81bf0a20f418f56365aa2065fea29



I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy
-P jacoco -P japicmp clean package site deploy' using:

openjdk version "17.0.12" 2024-07-16
OpenJDK Runtime Environment Homebrew (build 17.0.12+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.12+0, mixed mode, sharing)

Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256)
Maven home: /usr/local/Cellar/maven/3.9.8/libexec
Java version: 17.0.12, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@17/17.0.12/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac"

Darwin  23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:09:52
PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64

Details of changes since 71 are in the release notes:

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

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

Site:
https://dist.apache.org/repos/dist/dev/commons/parent/72-RC1/site/index.html
(note some *relative* links are broken and the 72 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/72-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-72-RC1 commons-parent-72-RC1
cd commons-parent-72-RC1

1b) Download and unpack the source archive from:

https://dist.apache.org/repos/dist/dev/commons/parent/72-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:

JDK 23 RDP2 | Removal of the legacy COMPAT locale provider and more heads-up!

[David Delabassee]

Welcome to the OpenJDK Quality Outreach summer update.

JDK 23 is now in Rampdown Phase Two [1], its overall feature has been frozen a 
few weeks ago. Per the JDK Release Process, we have now turned our focus to P1 
and P2 bugs, which can be fixed with approval [2]. Late enhancements are still 
possible, with approval, but the bar is now extraordinarily high. That also 
means that the JDK 23 Initial Release Candidates are fast approaching, i.e., 
August 8th [3]! So, and in addition to testing your projects with the latest 
JDK 23 early-access builds, it is now a good time to start testing with the JDK 
24 early-access builds.

Make sure to also check the heads-up below as some are related to JDK 23 and 
might have some impact, i.e., the first one being related to the eventual 
removal of the Security Manager and the second one discusses the removal of the 
legacy COMPAT locale provider.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-July/009252.html
[2] https://openjdk.org/jeps/3#rdp-2
[3] https://openjdk.org/projects/jdk/23/


## Heads-up - JDK 23: Subject.getSubject API Requires Allowing the Security 
Manager

In JDK 17 and as announced in JEP 411 [4], the Security Manager was deprecated 
for removal. As part of that change, several Security Manager APIs, such as 
`AccessControlContext`, were deprecated for removal. The `Subject::doAs` and 
`Subject::getSubject` APIs depend on Security Manager related APIs even though 
they do not require Security Manager to be installed to use them.

As of JDK 23 [5], to help applications prepare for the eventual removal of the 
Security Manager, subject authorization and the Subject APIs' behavior depend 
on allowing the Security Manager:
- If the system property `java.security.manager` is set on the command line to 
the empty string, a class name, or the value `allow` then there is no behavior 
change compared to previous releases.
- If the system property `java.security.manager` is not set on the command line 
or has been set on the command line to the value `disallow`, invoking the 
`Subject.getSubject` method will throw `UnsupportedOperationException`.

Yet, running an application with `-Djava.security.manager=allow` is a temporary 
workaround to keep older code working. Maintainers of code using `Subject.doAs` 
and `Subject.getSubject` are strongly encouraged to migrate it with utmost 
priority to the replacement APIs, `Subject.callAs` and `Subject.current`. Make 
sure to check [5] and [6] for additional details.

The jdeprscan tool [7] scans a JAR file for usage of deprecated API elements 
and is helpful to find code using these methods. Additionally, consider 
migrating as soon as possible code that stores a `Subject` in an 
`AccessControlContext` and invokes `AccessController.doPrivileged` with that 
context. Such code will stop working when the Security Manager is removed.

[4] https://openjdk.org/jeps/411
[5] https://jdk.java.net/23/release-notes#b15
[6] https://inside.java/2024/07/08/quality-heads-up/
[7] https://dev.java/learn/jvm/tools/core/jdeprscan/


## Heads-up - JDK 23: Unicode / Removal of COMPAT Locale Provider

### A Quick History of Locale Data in the JDK

Before the Unicode Consortium created the Common Locale Data Repository (CLDR) 
in 2003 to manage locale data, the JDK had to provide its own collection. It 
did so successfully and in JDK 8 supported about 160 locales. To reduce 
maintenance effort, allow better interoperability between platforms, and 
improve locale data quality, the JDK started to move towards CLDR in 2014:
- JDK 8 comes with two locale data providers, which can be selected with the 
system property java.locale.providers:
   . JRE/COMPAT for the JDK’s legacy data collection (default)
   . CLDR for the CLDR data
   . a custom locale provider can be implemented
- JDK 9 picks CLDR by default
- JDK 21 issues a warning on JRE/COMPAT

There are plenty of minor and a few notable differences between the legacy data 
and CLDR - the recently rewritten JEP 252 [8] lists a few of them.

### Locale Data in JDK 23

JDK 23 [9] removes legacy locale data. As a consequence, setting 
java.locale.providers to JRE or COMPAT has no effect.

Projects that are still using legacy locale data are highly encouraged to 
switch to CLDR as soon as possible. Where that is infeasible, two alternatives 
remain:
- Create custom formatters with patterns that mimic the legacy behavior and use 
them everywhere where locale-sensitive data is written or parsed.
- Implement a custom locale data provider [10].

For more details on that as well as on CLDR in the JDK in general, please check 
JEP 252 [8] that has been recently rewritten to provide better information and 
guidance.

[8] https://openjdk.org/jeps/252
[9] https://bugs.openjdk.org/browse/JDK-8325568
[10] 
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/spi/LocaleServiceProvider.html


## Heads-up - JDK 23:  Initial Leyden Early-Access Builds

Project Leyden published its first