Re: [lang] Considering a new String utility class

[Peter Verhas]

A few years ago when I refactored some code in this project, I created such
a class for myself, as I was experimenting at that time with how to
generate fluent API automatically. I will look it up where it is and give
here a pointer. That may be a starting point and as you can guessed from
the fact that I started to create something like that for myself I welcome
this idea.

I also submitted at some conferences talks on how to create a fluent API
front-end for Apache Commons Strings, but no one liked the idea as a
conference talk.

On Wed, Mar 15, 2023 at 1:58 PM Gary Gregory  wrote:

> PRs and issues like "[LANG-1682] Adding new startsWithAnyIgnoreCase
> method and tests cases" keep popping up from time to time.
>
> My preference is to stop adding APIs that are variations of other APIs
> based on case sensitivity (and Charset, Locale, and so on).
>
> Instead, I can see adding a new String utility class that tracks such
> attributes on its instance such that you'd say something like:
> - Strings.caseSensitive().someOperation(...)
> - Strings.caseInsensitive().someOperation(...).
>
> The 2 above would access pre-built instances probably. A builder would
> let you build an instance that your app can cache:
> Strings.builder().setCaseSensitivity(true).setCharset(...).build();
>
> An instance of Strings or whatever to call such a class would track
> case sensitivity, a Locale, and maybe an input and output Charset, I'm
> not 100% sure yet. But you get the idea I hope.
>
> Any thoughts?
>
> Gary
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-- 
Peter Verhas
pe...@verhas.com
t: +41791542095
skype: verhas

[all] Failed Jenkins builds

[Alex Herbert]

A recent update in Jenkins has updated some part of the Jenkins
tooling that reports on the job to a jar file compiled for Java 11.
This is making all the Java 8 Jenkins jobs fail.

I am not sure of the relevance of many of these Jenkins builds given
the use of GH actions for CI builds. The advantage of Jenkins builds
is to deploy SNAPSHOTS automatically to the snapshot repo. This is
useful for mutli-module projects where you are able to do a build
within one module from the current dev branch and the other
dependencies are pulled from the snapshot repo. It can also be used to
run the SonarCloud code quality analysis.

I suggest disabling the following builds that are failing due to Java
11 incompatibility in the job setup:

- commons-bcel
- commons-build-plugin
- commons-cli
- commons-codec
- commons-configuration
- commons-imaging
- commons-io
- commons-parent
- commons-validator

The configuration can be fixed if snapshot deployment is required in the future.

Alex

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

Re: [all] Failed Jenkins builds

[Gary Gregory]

All Commons components are Java 8 (or older), so all could be disabled? I
only rely on GitHub builds since it validates PRs. There is a way to make
releases from GH but I've not looked into it yet.

Gary

On Mon, Mar 20, 2023, 06:17 Alex Herbert  wrote:

> A recent update in Jenkins has updated some part of the Jenkins
> tooling that reports on the job to a jar file compiled for Java 11.
> This is making all the Java 8 Jenkins jobs fail.
>
> I am not sure of the relevance of many of these Jenkins builds given
> the use of GH actions for CI builds. The advantage of Jenkins builds
> is to deploy SNAPSHOTS automatically to the snapshot repo. This is
> useful for mutli-module projects where you are able to do a build
> within one module from the current dev branch and the other
> dependencies are pulled from the snapshot repo. It can also be used to
> run the SonarCloud code quality analysis.
>
> I suggest disabling the following builds that are failing due to Java
> 11 incompatibility in the job setup:
>
> - commons-bcel
> - commons-build-plugin
> - commons-cli
> - commons-codec
> - commons-configuration
> - commons-imaging
> - commons-io
> - commons-parent
> - commons-validator
>
> The configuration can be fixed if snapshot deployment is required in the
> future.
>
> Alex
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [all] Failed Jenkins builds

[Alex Herbert]

On Mon, 20 Mar 2023 at 10:26, Gary Gregory  wrote:
>
> All Commons components are Java 8 (or older), so all could be disabled? I
> only rely on GitHub builds since it validates PRs. There is a way to make
> releases from GH but I've not looked into it yet.

I do not want to waste my time fixing something that is not required.
I'd rather just turn them off for now and they can be fixed if needed
in the future.

I will configure the math derived multi-module components to run under
JDK 11 as snapshot deployment is useful. The SonarCloud analysis
already requires JDK 11 so these builds are fine.

Alex

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

Re: [lang] Considering a new String utility class

[Xeno Amess]

I agree if it doesn't hurt more than 5% performance.

From: Peter Verhas 
Sent: Monday, March 20, 2023 4:16:17 PM
To: Commons Developers List 
Subject: Re: [lang] Considering a new String utility class

A few years ago when I refactored some code in this project, I created such
a class for myself, as I was experimenting at that time with how to
generate fluent API automatically. I will look it up where it is and give
here a pointer. That may be a starting point and as you can guessed from
the fact that I started to create something like that for myself I welcome
this idea.

I also submitted at some conferences talks on how to create a fluent API
front-end for Apache Commons Strings, but no one liked the idea as a
conference talk.

On Wed, Mar 15, 2023 at 1:58 PM Gary Gregory  wrote:

> PRs and issues like "[LANG-1682] Adding new startsWithAnyIgnoreCase
> method and tests cases" keep popping up from time to time.
>
> My preference is to stop adding APIs that are variations of other APIs
> based on case sensitivity (and Charset, Locale, and so on).
>
> Instead, I can see adding a new String utility class that tracks such
> attributes on its instance such that you'd say something like:
> - Strings.caseSensitive().someOperation(...)
> - Strings.caseInsensitive().someOperation(...).
>
> The 2 above would access pre-built instances probably. A builder would
> let you build an instance that your app can cache:
> Strings.builder().setCaseSensitivity(true).setCharset(...).build();
>
> An instance of Strings or whatever to call such a class would track
> case sensitivity, a Locale, and maybe an input and output Charset, I'm
> not 100% sure yet. But you get the idea I hope.
>
> Any thoughts?
>
> Gary
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

--
Peter Verhas
pe...@verhas.com
t: +41791542095
skype: verhas

Re: [lang] Considering a new String utility class

[Xeno Amess]

Otherwise I doubt the cost...

From: Xeno Amess 
Sent: Monday, March 20, 2023 7:00:14 PM
To: Commons Developers List 
Subject: Re: [lang] Considering a new String utility class

I agree if it doesn't hurt more than 5% performance.

From: Peter Verhas 
Sent: Monday, March 20, 2023 4:16:17 PM
To: Commons Developers List 
Subject: Re: [lang] Considering a new String utility class

A few years ago when I refactored some code in this project, I created such
a class for myself, as I was experimenting at that time with how to
generate fluent API automatically. I will look it up where it is and give
here a pointer. That may be a starting point and as you can guessed from
the fact that I started to create something like that for myself I welcome
this idea.

I also submitted at some conferences talks on how to create a fluent API
front-end for Apache Commons Strings, but no one liked the idea as a
conference talk.

On Wed, Mar 15, 2023 at 1:58 PM Gary Gregory  wrote:

> PRs and issues like "[LANG-1682] Adding new startsWithAnyIgnoreCase
> method and tests cases" keep popping up from time to time.
>
> My preference is to stop adding APIs that are variations of other APIs
> based on case sensitivity (and Charset, Locale, and so on).
>
> Instead, I can see adding a new String utility class that tracks such
> attributes on its instance such that you'd say something like:
> - Strings.caseSensitive().someOperation(...)
> - Strings.caseInsensitive().someOperation(...).
>
> The 2 above would access pre-built instances probably. A builder would
> let you build an instance that your app can cache:
> Strings.builder().setCaseSensitivity(true).setCharset(...).build();
>
> An instance of Strings or whatever to call such a class would track
> case sensitivity, a Locale, and maybe an input and output Charset, I'm
> not 100% sure yet. But you get the idea I hope.
>
> Any thoughts?
>
> Gary
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

--
Peter Verhas
pe...@verhas.com
t: +41791542095
skype: verhas

Re: [all] Failed Jenkins builds

[Gary Gregory]

Snapshots are a convenience, not a requirement AFAIK, and I'm not going to
spin my wheels with Jenkins which is far less reliable than GitHub IMO.
I've seen too many builds fail on Jenkins and when I look, I see some weird
stack trace or git issue or something that I should not have to worry about
as a component developer.

Gary

On Mon, Mar 20, 2023, 06:40 Alex Herbert  wrote:

> On Mon, 20 Mar 2023 at 10:26, Gary Gregory  wrote:
> >
> > All Commons components are Java 8 (or older), so all could be disabled? I
> > only rely on GitHub builds since it validates PRs. There is a way to make
> > releases from GH but I've not looked into it yet.
>
> I do not want to waste my time fixing something that is not required.
> I'd rather just turn them off for now and they can be fixed if needed
> in the future.
>
> I will configure the math derived multi-module components to run under
> JDK 11 as snapshot deployment is useful. The SonarCloud analysis
> already requires JDK 11 so these builds are fine.
>
> Alex
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons Compress 1.23.0 based on RC1

[Bruno Kinoshita]

+1

Built from the tag with

Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
Maven home: /opt/apache-maven-3.8.5
Java version: 17.0.6, vendor: Private Build, runtime:
/usr/lib/jvm/java-17-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-67-generic", arch: "amd64", family:
"unix"

and with `mvn clean test install site`.

The SpotBugs issues need some cleaning. There are several entries including
some MALICIOUS_CODE issues. The current live site uses FindBugs, so it
could be false positives or just new rules in SpotBugs.

The only thing I noticed looking at the changes is that previous RM'er used
1.NN, instead of 1.NN.0, but that doesn't really matter IMO.

Rest of reports look good!

Thanks for RM'ing Gary!

Cheers

Bruno

On Sat, 18 Mar 2023 at 19:06, Gary Gregory  wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Compress 1.22 was released, so I would like to
> release Apache Commons Compress 1.23.0.
>
> Apache Commons Compress 1.23.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/1.23.0-RC1
> (svn revision 60704)
>
> The Git tag commons-compress-1.23.0-RC1 commit for this RC is
> b19df3e5b9a85000cf46be3afd998fc58c0ea538 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-compress.git;a=commit;h=b19df3e5b9a85000cf46be3afd998fc58c0ea538
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-compress.git
> --branch
> 
> commons-compress-1.23.0-RC1 commons-compress-1.23.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1628/org/apache/commons/commons-compress/1.23.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sat Mar 18 13:46:45 EDT 2023
>
> commons-compress-1.23.0-bin.tar.gz=67d49954c55c23693c233695502248b2544ee3c14e30395fb57f31ad3eccc9f19c461f1633c98f64a20b63e9124c5c4ff73cf11514583811e64bbde5e28eeacc
>
> commons-compress-1.23.0-bin.zip=e8a0cb7c9a90cd403e1c51f5ae4038d9314dc474394f71cb9d81167d770ec3853eac8490df76079a23d346ad312d1a9367aa3dcbd501f3d384f160046866cd91
>
> commons-compress-1.23.0-bom.json=87eecc373e31b4d43584bd320210f7101a974de05141247678583038470980cd9d0d3ae79bf146b9da0495297fbf587af455ca86e899449e9d9d5e061b4587ca
>
> commons-compress-1.23.0-bom.xml=2e2f58ef9df08b0daaf064b27746aa079ab4ca9a375947dac0611ffbb2f89569ea4ba948fa9d31c6b3ba5c578bcf9c457dc1d7cae234dcdeb036a33fc84c2558
>
> commons-compress-1.23.0-javadoc.jar=6c0e97f7827a17279c24eb26a908f4a1df2dae53dededb95c84695a8e8ca09ed6a7142da6729ed761cc591eb93fcd894ce64a5633d5a13f5feaf6871bfdb72da
>
> commons-compress-1.23.0-sources.jar=aa5fadb2d0b2454ef0fc04552178bc3d2b27828968129f93fb2b7cebe609e9a11e59624bf1d5b27568f3b8602eef2cb9f6d0ec544740ca32c9f381f73aad9121
>
> commons-compress-1.23.0-src.tar.gz=2715f69ae905a75ec0b98dddb56fb0ef146bbced250663d9483ab1c680eccaa8229a88374b5737088d283df0405dc76a1dee79e604152a3eb95a918dbd0cdd9f
>
> commons-compress-1.23.0-src.zip=2b94535cb66c8ebc89d388a1ca17b1b7ef6cc3661bb16c2d23734814ddc7359a97021c0140a000253087bb63ddaba5ab1951701e1fdc98907ddba5ab5c12376c
>
> commons-compress-1.23.0-test-sources.jar=78ad9e0d7e50de37110dd1d2b5f59bbba3762275502051d27154e58e68bd17f87fd7e1bef28ef3ff382a8008de4ea13bd6a449d26f412e1ee6cbb49241950c3d
>
> commons-compress-1.23.0-tests.jar=547dccbdfbca5b4f2219750057d732af2a7e5b5ee5ddcee74607d8c99473d97cca56e8f32b5685e5f1dc36277d1c52c8609985855f54eef7d614b2cfbd14ec85
>
> org.apache.commons_commons-compress-1.23.0.spdx.json=2a1a0ce5575375a5ce53297a173002a4f95b5edf8f1e00b50d6afff8674af3cd3e1affbe82bee1efeb86183f0abdbaba2fcc7bff37d95f5eecedf477e11b47af
>
> I have tested this with
>
> mvn -V -Duser.name=$my_apache_id
> -Dcommons.release-plugin.version=$commons_release_plugin_version
> -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
>
> Using:
>
> Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: /usr/local/Cellar/maven/3.9.1/libexec
> Java version: 1.8.0_362, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8
> /1.8.0+362/libexec/openjdk.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "13.2.1", arch: "x86_64", family: "mac"
>
> Darwin  22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30 20:42:11
> PST 2023; root:xnu-8792.81.3~2/RELEASE_X86_64 x86_64
>
> Details of changes since 1.22 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.23.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.23.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.23.0-RC1/site/index.html
> (note some *relative* links are broken and the 1.23.0 directories
> are not yet created - these will be OK once the site is de