Re: [commons-lang] branch master updated: Use Collection#toArray(new T[0]) instead of a presized array as it is faster on modern JVMs.

[Pascal Schumacher]

Feel free to revert the changes.

I would revert my changes, but Garry did some follow-up changes so these
would to be reverted first.

Am 27.12.2019 um 12:33 schrieb sebb:

As that article says in conclusion, T[0] seems currently faster, but that
may not always be the case with future VMs.

Also it says that IntelliJ IDEA and PMD recommend using T[size] rather than
T[0].
If we release code with T[0], I suspect we will get complaints that the
code is not efficient according to x, y and z.

I'm not convinced that the change is worth it, but if it is agreed the code
must be thoroughly documented to try and forestall complaints.
According to the article, using a constant empty array is faster, but only
marginally. If there is a constant available it would probably make sense
to use it.
This should also be documented, as it affects the return value for the
empty case.

S.
On Fri, 27 Dec 2019 at 09:28, Pascal Schumacher 
wrote:


see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

Am 27.12.2019 um 01:24 schrieb sebb:

Also, where is it documented that modern JVMs are faster?
To which JVMs does this apply?

S.

On Thu, 26 Dec 2019 at 22:08, Gary Gregory 

wrote:

Please do not cause garbage to apparently be generated all over the

place

by creating new empty arrays all the time. Use the constants Commons

Lang

constants already defines; see ArrayUtils.

Gary

On Thu, Dec 26, 2019 at 4:48 PM  wrote:


This is an automated email from the ASF dual-hosted git repository.

pascalschumacher pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/commons-lang.git


The following commit(s) were added to refs/heads/master by this push:
   new 84668a2  Use Collection#toArray(new T[0]) instead of a

presized

array as it is faster on modern JVMs.
84668a2 is described below

commit 84668a2d980316a580030fd64764cb072b520b09
Author: pascalschumacher 
AuthorDate: Thu Dec 26 22:48:12 2019 +0100

  Use Collection#toArray(new T[0]) instead of a presized array as

it is

faster on modern JVMs.
---
   src/main/java/org/apache/commons/lang3/CharSet.java|  2

+-

   src/main/java/org/apache/commons/lang3/StringUtils.java| 10
+-
   .../org/apache/commons/lang3/exception/ExceptionUtils.java |  6

+++---

   src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java |  4

++--

   .../java/org/apache/commons/lang3/reflect/MethodUtils.java |  2

+-

   src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java  |  2

+-

   src/main/java/org/apache/commons/lang3/text/StrTokenizer.java  |  4

++--

   .../org/apache/commons/lang3/time/DurationFormatUtils.java |  2

+-

   .../java/org/apache/commons/lang3/time/FastDatePrinter.java|  2

+-

   .../commons/lang3/concurrent/EventCountCircuitBreakerTest.java |  2

+-

   10 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/src/main/java/org/apache/commons/lang3/CharSet.java
b/src/main/java/org/apache/commons/lang3/CharSet.java
index 3fdfd07..7955115 100644
--- a/src/main/java/org/apache/commons/lang3/CharSet.java
+++ b/src/main/java/org/apache/commons/lang3/CharSet.java
@@ -225,7 +225,7 @@ public class CharSet implements Serializable {
   // NOTE: This is no longer public as CharRange is no longer a public
class.
   //   It may be replaced when CharSet moves to Range.
   /*public*/ CharRange[] getCharRanges() {
-return set.toArray(new CharRange[set.size()]);
+return set.toArray(new CharRange[0]);
   }




//---

diff --git a/src/main/java/org/apache/commons/lang3/StringUtils.java
b/src/main/java/org/apache/commons/lang3/StringUtils.java
index abde7ec..d629806 100644
--- a/src/main/java/org/apache/commons/lang3/StringUtils.java
+++ b/src/main/java/org/apache/commons/lang3/StringUtils.java
@@ -7507,7 +7507,7 @@ public class StringUtils {
   currentType = type;
   }
   list.add(new String(c, tokenStart, c.length - tokenStart));
-return list.toArray(new String[list.size()]);
+return list.toArray(new String[0]);
   }

   /**
@@ -7735,7 +7735,7 @@ public class StringUtils {
   }
   }

-return substrings.toArray(new String[substrings.size()]);
+return substrings.toArray(new String[0]);
   }

   //
---
@@ -7923,7 +7923,7 @@ public class StringUtils {
   if (match || preserveAllTokens && lastMatch) {
   list.add(str.substring(start, i));
   }
-return list.toArray(new String[list.size()]);
+return list.toArray(new String[0]);
   }

   /**
@@ -8022,7 +8022,7 @@ public class StringUtils {
   if (match || preserveAllTokens && lastMatch) {
   list.add(str.substring(start, i));
   }
-return list.toArray(new String[list.size()]);
+ret

Re: [commons-lang] branch master updated: Use Collection#toArray(new T[0]) instead of a presized array as it is faster on modern JVMs.

[Pascal Schumacher]

see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

Am 27.12.2019 um 01:24 schrieb sebb:

Also, where is it documented that modern JVMs are faster?
To which JVMs does this apply?

S.

On Thu, 26 Dec 2019 at 22:08, Gary Gregory  wrote:


Please do not cause garbage to apparently be generated all over the place
by creating new empty arrays all the time. Use the constants Commons Lang
constants already defines; see ArrayUtils.

Gary

On Thu, Dec 26, 2019 at 4:48 PM  wrote:


This is an automated email from the ASF dual-hosted git repository.

pascalschumacher pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/commons-lang.git


The following commit(s) were added to refs/heads/master by this push:
  new 84668a2  Use Collection#toArray(new T[0]) instead of a presized
array as it is faster on modern JVMs.
84668a2 is described below

commit 84668a2d980316a580030fd64764cb072b520b09
Author: pascalschumacher 
AuthorDate: Thu Dec 26 22:48:12 2019 +0100

 Use Collection#toArray(new T[0]) instead of a presized array as it is
faster on modern JVMs.
---
  src/main/java/org/apache/commons/lang3/CharSet.java|  2 +-
  src/main/java/org/apache/commons/lang3/StringUtils.java| 10
+-
  .../org/apache/commons/lang3/exception/ExceptionUtils.java |  6

+++---

  src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java |  4 ++--
  .../java/org/apache/commons/lang3/reflect/MethodUtils.java |  2 +-
  src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java  |  2 +-
  src/main/java/org/apache/commons/lang3/text/StrTokenizer.java  |  4 ++--
  .../org/apache/commons/lang3/time/DurationFormatUtils.java |  2 +-
  .../java/org/apache/commons/lang3/time/FastDatePrinter.java|  2 +-
  .../commons/lang3/concurrent/EventCountCircuitBreakerTest.java |  2 +-
  10 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/src/main/java/org/apache/commons/lang3/CharSet.java
b/src/main/java/org/apache/commons/lang3/CharSet.java
index 3fdfd07..7955115 100644
--- a/src/main/java/org/apache/commons/lang3/CharSet.java
+++ b/src/main/java/org/apache/commons/lang3/CharSet.java
@@ -225,7 +225,7 @@ public class CharSet implements Serializable {
  // NOTE: This is no longer public as CharRange is no longer a public
class.
  //   It may be replaced when CharSet moves to Range.
  /*public*/ CharRange[] getCharRanges() {
-return set.toArray(new CharRange[set.size()]);
+return set.toArray(new CharRange[0]);
  }




//---

diff --git a/src/main/java/org/apache/commons/lang3/StringUtils.java
b/src/main/java/org/apache/commons/lang3/StringUtils.java
index abde7ec..d629806 100644
--- a/src/main/java/org/apache/commons/lang3/StringUtils.java
+++ b/src/main/java/org/apache/commons/lang3/StringUtils.java
@@ -7507,7 +7507,7 @@ public class StringUtils {
  currentType = type;
  }
  list.add(new String(c, tokenStart, c.length - tokenStart));
-return list.toArray(new String[list.size()]);
+return list.toArray(new String[0]);
  }

  /**
@@ -7735,7 +7735,7 @@ public class StringUtils {
  }
  }

-return substrings.toArray(new String[substrings.size()]);
+return substrings.toArray(new String[0]);
  }

  //
---
@@ -7923,7 +7923,7 @@ public class StringUtils {
  if (match || preserveAllTokens && lastMatch) {
  list.add(str.substring(start, i));
  }
-return list.toArray(new String[list.size()]);
+return list.toArray(new String[0]);
  }

  /**
@@ -8022,7 +8022,7 @@ public class StringUtils {
  if (match || preserveAllTokens && lastMatch) {
  list.add(str.substring(start, i));
  }
-return list.toArray(new String[list.size()]);
+return list.toArray(new String[0]);
  }

  /**
@@ -8835,7 +8835,7 @@ public class StringUtils {
  if (list.isEmpty()) {
  return null;
  }
-return list.toArray(new String[list.size()]);
+return list.toArray(new String[0]);
  }

  /**
diff --git
a/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java
b/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java
index 5969614..dd154e3 100644
---

a/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java

+++

b/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java

@@ -274,7 +274,7 @@ public class ExceptionUtils {
  }
  frames.addAll(trace);
  }
-return frames.toArray(new String[frames.size()]);
+return frames.toArray(new String[0]);
  }

  /**
@@ -325,7 +325,7 @@ public class ExceptionUtils {
  while (frames.hasMoreTokens()) {
  list.add(frames.nextToken());
  

Re: [VOTE] Release Apache Commons RNG 1.3 based on RC1

[Pascal Schumacher]

+1

Am 05.11.2019 um 17:36 schrieb Alex Herbert:

We have fixed quite a few bugs and added some significant enhancements
since Apache Commons RNG 1.2 was released, so I would like to release
Apache Commons RNG 1.3.

Apache Commons RNG 1.3 RC1 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/
  https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/

Tag name:
  RNG_1_3_RC1 (signature can be checked from git using 'git tag -v
RNG_1_3_RC1')

Tag URL:
https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=43f290e68c31e5bea6cde97c7e999c2e1f2562b2


Commit ID the tag points at:
  43f290e68c31e5bea6cde97c7e999c2e1f2562b2

Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1476/org/apache/commons/


These are the artifacts and their SHA 512 hashes:
310c0582b80c60fb159846f9615c7952b3c405265955392d77b16d7cfac9e8c5f2c680686e526b412ab8b4356ef9ecd07977764c31db8e02bef40e37b47ac27a
commons-rng-1.0-bin.tar.gz
e0247ea82aff57cc86ac904ae482c193b7edd5253d26f87fc590b50a738d5fa5c4a6b3b24cd6a48c459e18156ade2588d8c9d12c9a04d15570780240d29ef406
commons-rng-1.0-bin.zip
f33b922a9d8bc6098bd0e9a98859b17e1cdda21922f136b568868b21af274fdf3d78456a5c73c26c665205a22493836d59b1d33822c4a5c58e82ba64eadcb5e1
commons-rng-1.0-src.tar.gz
ef4fe63ebbd76e8d95b5f054fed76a40a85f5dd99ca2406a31fb95b593ed3d96b29389bf82424e18895192751689d7590404c8b1d90b28878271c79cad3be18b
commons-rng-1.0-src.zip

The source code contains examples that are not part of the public API.
These examples contain Java 9 modules and are enabled using a profile
(see below).

An error when building the Java 9 modules site/javadoc under JDK 11 is
a known issue as the javadoc command errors when documenting Java 9
modules that include code from the unamed module.

Note: Testing randomness using statistical thresholds results in
failures at a given probability. The 'maven-surefire-plugin' is
configured to re-run tests that fail, and pass the build if they
succeed within the allotted number of reruns (the test will be marked
as 'flaky' in the report).

I have tested this with:

'mvn clean install site' using:

***
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T19:41:47+01:00)
Maven home: /usr/local/apache-maven-3.6.0
Java version: 1.8.0_222, vendor: Private Build, runtime:
/usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
"unix"
***

***
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T19:41:47+01:00)
Maven home: /usr/local/apache-maven-3.6.0
Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
/usr/lib/jvm/jdk-11.0.5+10
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
"unix"
***

Java 9 modules in the examples modules.

'mvn -Pcommons-rng-examples clean install site' using:

***
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T19:41:47+01:00)
Maven home: /usr/local/apache-maven-3.6.0
Java version: 9, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-9
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
"unix"
***

'mvn -Pcommons-rng-examples clean install' using:

***
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T19:41:47+01:00)
Maven home: /usr/local/apache-maven-3.6.0
Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
/usr/lib/jvm/jdk-11.0.5+10
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
"unix"
***

Details of changes since 1.2 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/RELEASE-NOTES.txt

https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/changes-report.html


Site:
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/index.html
    (note some *relative* links are broken and the 1.3 directories are
not yet created - these will be OK once the site is deployed.)

CLIRR Report (compared to 1.2):
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-client-api/clirr-report.html

https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-core/clirr-report.html

https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-simple/clirr-report.html

https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-sampling/clirr-report.html


RAT Report:
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/rat-report.html


KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 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,

Alex Herbert,
Release Manager (using key 

Re: [IO] Don't deprecate IOUtils#closeQuietly()

[Pascal Schumacher]

+1, for removing the deprecatio

Am 05.11.2019 um 16:10 schrieb Gary Gregory:

Hi All:

I propose that we do NOT deprecate IOUtils#closeQuietly(). There are
use-cases for this method outside of try-with-resources blocks.

For example, I have some wrapper objects that contain Closeable objects.
When the wrapper is closed, I do and want to add calls to
IOUtils#closeQuietly() to avoid null checks in call sites.

Gary




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

Re: [exec] Update from Java 5 to 6

[Pascal Schumacher]

+1

Am 09.10.2019 um 17:25 schrieb John Patrick:

What about Java 5 to 8.
I'm current sat at Jax London and was the sole person who put their
hand up for Java 6, and next Conference I hope to have migrated
everything to at least Java 8. From the rest I saw 1 hand being raised
for Java 7, about 2/3rd's said Java 8 and 1/3rd said Java 11, with a
handful saying Java 12 or 13.

On Wed, 9 Oct 2019 at 14:12, Gary Gregory  wrote:

Hi All,

I'd like to update Commons Exec from Java 5 to 6 to get it to build on Java
11.

Gary

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




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

Re: [VOTE] Release Apache Commons BCEL 6.4.1 based on RC1

[Pascal Schumacher]

+1

Am 29.09.2019 um 18:23 schrieb Gary Gregory:

My +1

Gary

On Thu, Sep 26, 2019 at 9:38 PM Gary Gregory  wrote:


We have fixed one important bug since Apache Commons BCEL 6.4.0 was
released, so I would like to release Apache Commons BCEL 6.4.1.

Apache Commons BCEL 6.4.1 RC1 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/bcel/6.4.1-RC1 (svn
revision 36085)

The Git tag commons-bcel-6.4.1-RC1 commit for this RC is
bebe70de81f2f8912857ddb33e82d3ccc146a24e which you can browse here:

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

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1472/org/apache/bcel/bcel/6.4.1/

These are the artifacts and their hashes:

#Release SHA-512s
#Thu Sep 26 21:15:47 EDT 2019

bcel-6.4.1-bin.tar.gz=937994f22aaaf7dfe1f9a789f6c9968f80b5c9a2929aa0364beffe1b9136f7af98dd6386533f02441f74a9df57e913b4eb9c0598778f31d4ea3cda9b02beabcb

bcel-6.4.1-bin.zip=94bcd0afa9f6679f7d0e25b5bf3d2901d7e42f4488f6b7f2a5b91827023ca56ef6c5bf2b82996ec196d2b744f1345526f729dc00b3fb58d4b55f8fa7748e5fa1

bcel-6.4.1-javadoc.jar=280a79bc811c4c8b9c0249ba98d82a0054dd286ee1009f340231ac9d147709e06800e50c26fd21d8f31d15ab337a9ae30727edd8548f269d968ca7f31eb72abf

bcel-6.4.1-sources.jar=5761d9e1ba53b9d60f81941f1db581030aaadb5829f429c2897220c13874a7718e26f213bd9f49bbed68fb0a3a8e6375f312ce4c8cd551030d95652209aa7ab2

bcel-6.4.1-src.tar.gz=746987c314d3a2bd7308e5cd0b3403c915f09b5127af5980f986a81bccff91cca6098b636fd2f337e8e42f1e3600e8eac14b4f3b0564739b155955603a2e9b7f

bcel-6.4.1-src.zip=b63f3d53ec3c9cc623475c2383e292aa5fd52f1a8388c162a86b345efd82b3ba199b3ff096baf9a7a4767317b0c928d828c01154394e39bcecf9577668d7b1a6

bcel-6.4.1-test-sources.jar=28dd0b17d43552b9b91aed3c1fac042b388f50deaf3953930ce69906e8269ae5850dd402b93f7641266c665c6fd72069f025a590a6f39e907b084ea4db100517

bcel-6.4.1-tests.jar=5168dab87d4b49861f4dc8e0fc3522e26175a5faa3010cb5127b0455190c16246f35cf0b86b48ecdc92e4b4107197cef3c1265aade6ba630eb32dcd87ceb9fd7

I have tested this with:

mvn -V -Duser.name=%my_apache_id%
-Dcommons.release-plugin.version=1.7-SNAPSHOT -Ddoclint=none -Prelease
-Ptest-deploy clean package site deploy

using:

Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-27T11:06:16-04:00)
Maven home: C:\Java\apache-maven-3.6.2\bin\..
Java version: 1.8.0_221, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_221\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Details of changes since 6.4.0 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.4.1-RC1/RELEASE-NOTES.txt

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

Site:

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

JApiCmp Report (compared to 6.4.0):

https://dist.apache.org/repos/dist/dev/commons/bcel/6.4.1-RC1/site/japicmp.html

RAT Report:

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

KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 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)

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

1) Clone and checkout the RC tag

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

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

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: 

Re: [VOTE] Release Apache Commons Configuration 2.6 based on RC1

[Pascal Schumacher]

+1

Am 14.09.2019 um 03:23 schrieb Gary Gregory:

We have fixed a few bugs and added some enhancements since Apache Commons
Configuration 2.5 was released, so I would like to release Apache Commons
Configuration 2.6.

Apache Commons Configuration 2.6 RC1 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/configuration/2.6-RC1
(svn revision 35830)

The Git tag commons-configuration-2.6-RC1 commit for this RC is
32d6be96f6b101dfd18d21d79788980ee08e5965 which you can browse here:

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

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1469/org/apache/commons/commons-configuration2/2.6/

These are the artifacts and their hashes:

#Release SHA-512s
#Fri Sep 13 21:09:00 EDT 2019
commons-configuration2-2.6-bin.tar.gz=f4a6bc8aa066c53a74eefcea75d17e602ced8f8bc57c69ef342091b61b73ea511b38b82d4b5d519d12bb24bf99bd3ca48c9e83d40cf5b8c0d074694efc2d4859
\commons-configuration2-2.6-bin.zip=3c1ff55c7a0bed2e577557979650c44b34e93d591a36484000adea06043fb158e4824829a09dd6f3368db6752a85f11e5c2f538670a0a6c73c2a6227450f896e
commons-configuration2-2.6-javadoc.jar=3efe4fcb28e0cc6d26b97eb911fcd0de6f11e4ef371e69f215aecb1ca7789805ba4b89ea7862b2140538be30ad77d38cfeff6bb1fd4896498b8678f7c1c5ad5d
commons-configuration2-2.6-sources.jar=f90209da07281a22c0761840bdd90bcebd2992c5e85c565c9df4bb7efb4dbc7962b2543e85f30e2186e2a235fe1c458da793b2e37c39c5c5c43aa580a10b2c66
commons-configuration2-2.6-src.tar.gz=dd22a7dcaab4fb0160df50242c0e2c2bd91ec223a2725c12bbb8a873bbc1e365733d64c3521f6e580003161dbe3ea159f83da755a736ff7152bb49f4eda3e167
commons-configuration2-2.6-src.zip=2ea6031054fc606b94b6957056d09b61251ca3fc2a32fb6a26bf59a6eda7dba55b2b9c46bac30a4931bc776929bba8bc1e6360e9e1c2e2bf026740dcbd30fdc9
commons-configuration2-2.6-test-sources.jar=fe032ba3ffc3fbc1bdb51d6525421e43962617accdbe7a969e6e8e254c634d8f7d079a7eec78216c6f34e9a8c583f096eaaa7b2440f8194fdfa0e89b8eaff069
commons-configuration2-2.6-tests.jar=294970a14771866593efcc6164916d31bb1877c484dbc52881da173fa50eb34509f3a4817eeb6bfb911b6dd1d1c711635e5856ee77d921de13453c2d69ca0cf2

I have tested this with

mvn -V -Prelease -Pjacoco -Ptest-deploy clean package site deploy

using:

Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-27T11:06:16-04:00)
Maven home: C:\Java\apache-maven-3.6.2\bin\..
Java version: 1.8.0_221, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_221\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Details of changes since 2.5 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.6-RC1/RELEASE-NOTES.txt

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

Site:

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

JApiCmp Report (compared to 2.5):

https://dist.apache.org/repos/dist/dev/commons/configuration/2.6-RC1/site/japicmp.html

Note that this release adds new _default_ methods to interfaces which are
binary compatible.

RAT Report:

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

KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 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)

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

1) Clone and checkout the RC tag

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

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 

Re: [lang] Missing Javadocs

[Pascal Schumacher]

Checkstyle can be used to enforce the presence of javadoc.

At least the Travis CI build executes checkstyle and fails if checkstyle
fails.

Am 05.09.2019 um 18:04 schrieb sebb:

Can the CI build be changed to fail the build when Javadoc is omitted?

On Thu, 5 Sep 2019 at 17:00, Gary Gregory  wrote:

Hi All:

The following interfaces were added a while back without class-level
Javadoc:

org.apache.commons.lang3.Functions.FailableBiConsumer
org.apache.commons.lang3.Functions.FailableBiFunction
org.apache.commons.lang3.Functions.FailableBiPredicate
org.apache.commons.lang3.Functions.FailableCallable
org.apache.commons.lang3.Functions.FailableConsumer
org.apache.commons.lang3.Functions.FailableFunction
org.apache.commons.lang3.Functions.FailablePredicate
org.apache.commons.lang3.Functions.FailableRunnable
org.apache.commons.lang3.Functions.FailableSupplier

Would the original author, Jochen, or someone... chip in (again) please?

Gary

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




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

Re: [All] Source Repo page

[Pascal Schumacher]

+1

Am 12.08.2019 um 14:48 schrieb Gary Gregory:

Hi All,

I'm thinking that our components source repo page should also include a
link to the GitHub version of the repo.

Thoughts?

Gary




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

Re: [All][parent] RAT check

[Pascal Schumacher]

+1

Am 10.08.2019 um 16:42 schrieb Gary Gregory:

Hi all,

It seems to me the commons-parent should cause the RAT check to run for all
builds, say in the... validate phase?

Gary




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

Re: [IO] Travis builds fail for Java 7, 13 and ea

[Pascal Schumacher]

Build is green now.

Thanks for reporting!

Cheers,
Pascal

Am 02.08.2019 um 16:24 schrieb Pascal Schumacher:

Java 7 is not available on travis anymore.

Java 13+ fails because of incorrect javadoc:

An error has occurred in Javadoc report generation:
3336[ERROR] Exit code: 1 -
/home/travis/build/apache/commons-io/src/main/java/org/apache/commons/io/DirectoryWalker.java:49:

error: heading used out of sequence: , compared to implicit
preceding heading: 
3337[ERROR] * 1. Example Implementation
...

Am 01.08.2019 um 23:45 schrieb Rob Spoor:

See subject. This occurs for both master and pull requests. For
instance:
https://travis-ci.org/apache/commons-io/builds/561807075?utm_source=github_status_medium=notification


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







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

Re: [VOTE] Release Apache Commons BeanUtils 1.9.4 based on RC2

[Pascal Schumacher]

+1

Am 29.07.2019 um 00:35 schrieb Rob Tompkins:

We have fixed quite a few bugs and added some significant enhancements since 
Apache Commons BeanUtils 1.9.3 was released, so I would like to release Apache 
Commons BeanUtils 1.9.4.

Apache Commons BeanUtils 1.9.4 RC2 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/beanutils/1.9.4-RC2 (svn 
revision 35044)

The Git tag commons-beanutils-1.9.4-RC2 commit for this RC is
32ceb2c92512d44f97638805e2f3fd9d70dfcfc6 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-beanutils.git;a=commit;h=32ceb2c92512d44f97638805e2f3fd9d70dfcfc6
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-beanutils.git --branch
commons-beanutils-1.9.4-RC2 commons-beanutils-1.9.4-RC2

Maven artifacts are here:
 
https://repository.apache.org/content/repositories/orgapachecommons-1455/commons-beanutils/commons-beanutils/1.9.4/

These are the Maven artifacts and their hashes in Nexus:

#Nexus SHA-1s
commons-beanutils-1.9.4.jar=d52b9abcd97f38c81342bb7e7ae1eee9b73cba51
commons-beanutils-1.9.4-tests.jar=bf66a5197f0abb2c44d68a59e70487f5710c679a
commons-beanutils-1.9.4-javadoc.jar=6daf5afaab5f8d1c578d72c548d84b4e15b91c6c
commons-beanutils-1.9.4.pom=42e7c39331e1735250b294ce2984d0e434ebc955
commons-beanutils-1.9.4-sources.jar=f00e0ba867d1810f255876631ab440e0725a9af0
commons-beanutils-1.9.4-test-sources.jar=f97fc6a1b742bc18f1a80963d1e82d9d28fd5404

#Release SHA-256s
#Sun Jul 28 18:16:53 EDT 2019
commons-beanutils-1.9.4-src-tar.gz=2d46a5ac37000cad57ed338dbc5a0ae08cb924471afb5b3d4cff084afa0c728e
commons-beanutils-1.9.4-src-zip=48e12cff3d3621d2055ec0dfdf49a416bfe3e50bf0768488da878bbcca77d599
commons-beanutils-1.9.4-bin-tar.gz=313682f4a13b5b8f3c5e7e6351605f62ff431913c51b6ed94cc83563086e4295
commons-beanutils-1.9.4-bin-zip=02093566d50497e6cc732b561c74b1ce226c0e6fe7a679c91c2113689bb1a547


I have tested this with 'mvn clean install site' using:
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 
2019-04-04T15:00:29-04:00)
Maven home: /usr/local/Cellar/maven/3.6.1/libexec
Java version: 1.8.0_202, vendor: Amazon.com Inc., runtime: 
/Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"


Details of changes since 1.9.3 are in the release notes:
 
https://dist.apache.org/repos/dist/dev/commons/beanutils/1.9.4-RC2/RELEASE-NOTES.txt
 
https://dist.apache.org/repos/dist/dev/commons/beanutils/1.9.4-RC2/site/changes-report.html

Site:
 https://dist.apache.org/repos/dist/dev/commons/beanutils/1.9.4-RC2/site
 (note some *relative* links are broken and the 1.9.4 directories are not 
yet created - these will be OK once the site is deployed.)

RAT Report:
 
https://dist.apache.org/repos/dist/dev/commons/beanutils/1.9.4-RC2/site/rat-report.html

KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 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,

Rob Tompkins,
Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314)
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




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

Re: [IO] Travis builds fail for Java 7, 13 and ea

[Pascal Schumacher]

Java 7 is not available on travis anymore.

Java 13+ fails because of incorrect javadoc:

An error has occurred in Javadoc report generation:
3336[ERROR] Exit code: 1 -
/home/travis/build/apache/commons-io/src/main/java/org/apache/commons/io/DirectoryWalker.java:49:
error: heading used out of sequence: , compared to implicit
preceding heading: 
3337[ERROR] * 1. Example Implementation
...

Am 01.08.2019 um 23:45 schrieb Rob Spoor:

See subject. This occurs for both master and pull requests. For
instance:
https://travis-ci.org/apache/commons-io/builds/561807075?utm_source=github_status_medium=notification

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

Re: [VOTE] Release Apache Commons Pool 2.7.0 based on RC1

[Pascal Schumacher]

+1

Am 25.07.2019 um 16:59 schrieb Gary Gregory:

We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Pool 2.6.2 was released, so I would like to release
Apache Commons Pool 2.7.0.

Apache Commons Pool 2.7.0 RC1 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/pool/2.7.0-RC1 (svn
revision 35022)

The Git tag commons-pool-2.7.0-RC1 commit for this RC is
f4455dcb8afaf9ae7054589110f1082a7a8a282c which you can browse here:

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

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1454/org/apache/commons/commons-pool2/2.7.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Thu Jul 25 10:43:49 EDT 2019
commons-pool2-2.7.0-bin.tar.gz=5da53ee485b156fe428c18a1131ff762ca672e759ea84aa58d73155fba78ee3ce8421a1cfea6735e041b9770101e3889da4d51ffc30879fd583dc8f961bae1ed
commons-pool2-2.7.0-bin.zip=f03f95b45b42e4fdc799974911cc8cba57feca74c3c8eda7ce710c2f8eaaef2329491746397db901c3c3a251b3a2cc524245128a61121c2d1443272baaa1c67e
commons-pool2-2.7.0-javadoc.jar=a5a879e421d6063f721c20ccafba60550255b542b6d9cfc226a045a8fa2fb3a1758d61f8efd8f563d63d20ab9b29a966436e589a5f4beb1ea7d19665248fcdf1
commons-pool2-2.7.0-javadoc.jar.asc=003b0f60396671356c72f0203e17522b8ba035a45c7864efc3aa835c49809f73a6e5b7d8bd75c7125306d659a61e283af8e64f4f607920f5bf929ff052e3b2da
commons-pool2-2.7.0-sources.jar=22fad51648d23e11d0a881faf1748b9633e8a5b8d0ccc1334554abd6330796254c174405b2fbf6d901ea729e50feb3e0b9d51fb12dc7ab1bce803b26faf1366d
commons-pool2-2.7.0-src.tar.gz=2028df7c0306a01406b2f529f55898cc6db00a939731659eb86fc4d890f57bc55dbbf6cee777b406c9bc4c618218c0250b0dae236f8ddde58bcdcabf5afe6755
commons-pool2-2.7.0-src.zip=243ceba67abfcf621c6ceddbf30b52e2b84b453cb722294fb24a7db319f81a4668f9a3ebaf264e50becd50ea5822a82bb75c6303aec0ba57073cd628ea9938b2
commons-pool2-2.7.0-test-sources.jar=95605f34e415ad9c5de2bed7e54ed2b40bdfb2cabfccd23030b0a63362a258b082c798daa5f99ef35e149f8d733aa852449e73e0f91071272b79a52cf13629af
commons-pool2-2.7.0-tests.jar=08818d2d106ea1c9b7bf2f6f67cae13c4eaf47fb25100c9285491647ea93cd30d7ed5c8a49907fa0e581d060f073ff5f63612f1b43af2829ee229d64ce2c7f23

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.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T15:00:29-04:00)
Maven home: C:\Java\apache-maven-3.6.1\bin\..
Java version: 1.8.0_221, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_221\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Details of changes since 2.6.2 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/pool/2.7.0-RC1/RELEASE-NOTES.txt

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

Site:

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

JApiCmp Report (compared to 2.6.2):

https://dist.apache.org/repos/dist/dev/commons/pool/2.7.0-RC1/site/japicmp.html
 This release adds new default methods to the interface
org.apache.commons.pool2.PooledObject which does not break binary
compatibility.

RAT Report:

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

KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 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)

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

1) Clone and checkout the RC tag

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

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

This component uses 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 

Re: [VOTE] Release Apache Commons Codec 1.13 based on RC1

[Pascal Schumacher]

+1

Am 22.07.2019 um 03:05 schrieb Bruno P. Kinoshita:

  [x] +1 Release these artifacts

Passing with `mvn clean test install site -e -X` on:

$ mvn -v
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 
2017-10-18T20:58:13+13:00)
Maven home: /opt/apache-maven-3.5.2
Java version: 1.8.0_172, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0_172/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-54-generic", arch: "amd64", family: "unix"

and also successfully built from src sources (from dist) on:
$ JAVA_HOME=/c/Program\ Files/Java/jdk1.8.0_144/ 
~/Development/java/apache-maven-3.6.1/bin/mvn -v
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 
2019-04-05T08:00:29+13:00)
Maven home: C:\Users\kinoshitabd\Development\java\apache-maven-3.6.1
Java version: 1.8.0_144, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk1.8.0_144\jre
Default locale: en_NZ, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
A few new CheckStyle, FindBugs, and TagList issues, but none too severe to be a 
blocker (still nice to fix them later).
Notice, license, and other files look OK in dist area archives. Didn't have 
time to test Maven artefacts or check signatures.

Cheers
Bruno



 On Sunday, 21 July 2019, 3:54:59 am NZST, Gary Gregory 
 wrote:

  We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Codec 1.12 was released, so I would like to release
Apache Commons Codec 1.13.

Apache Commons Codec 1.13 RC1 is available for review here:
     https://dist.apache.org/repos/dist/dev/commons/codec/1.13-RC1 (svn
revision 34953)

The Git tag commons-codec-1.13-RC1 commit for this RC is
20dc3ec2c6b41f9412ecf4a1cbe9bba10e1498ed which you can browse here:

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

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1449/commons-codec/commons-codec/1.13/

These are the artifacts and their hashes:

#Release SHA-512s
#Sat Jul 20 11:35:51 EDT 2019
commons-codec-1.13-bin.tar.gz=5a0fe25d2ec5f06794e523b699e6758d76517c45b5edf88e5eb256c1ea8bb14f11f10e381ffe400e883acf572f44e2b99653f019b114c119a0ffbb23f4b0d4cc
commons-codec-1.13-bin.zip=c0e2ca7e350c6f100e5e1d104f04bd36df752aa5a69b1f42dae74b1a1d9fee3cb272b87afdec0d90540decb1c97886ec2aa3ca679ce9e84ca9449bb7af8ef36a
commons-codec-1.13-javadoc.jar=fbf608a2fb32ea31320efc8fc2a4a6276e56590c689d83aa3e587ce4e0346c6816f70f3ef18e72eacdbd3fefaba941f05ac01b6c5d5596b0f10ff4ac96980fb1
commons-codec-1.13-sources.jar=9cd7253f6e75318bc76a8d15090b3d9e31424bb1a2b362513f1901c4701886fe09100e78037c5a9e784c7839072b61c42f84a4197f5bfd2f5e9ed35836b39463
commons-codec-1.13-src.tar.gz=ffe1605ff2d094bc5d95d83f0871cef13866bf05bdfc32e05b1d20bdbc2002377f3bf8571aa0ad3c7a9936e18f8ccdc62a13c2ebd67baf07a5f04811d4c495fb
commons-codec-1.13-src.zip=d933bc7de919d62ec30be0b0a4e5c99f9101c543c7f28c60e2138acc4c78763f3d636f2d2e5fc66de54476a72057ee8a03c44d598ed17aef2f47051052d65c3f
commons-codec-1.13-test-sources.jar=269d2f88331040217c2c7b78c2bc6fb4f8e73484c29d52837d7977766fe6f9cd8ab789720996a5b81fceae9b8e21e0cb6acfecebb1b7a9a53158147357acca3e
commons-codec-1.13-tests.jar=a4b55cdaa7ec09058001b0d92dc8fe002c5db044a8eb7da0703c3bf02b2a4c2b3276565d89d96c16ae0210c598dfca2247295b4532ef15487be2eaa019474efb

I have tested this with 'mvn -V clean install site' using:

Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T15:00:29-04:00)
Maven home: C:\Java\apache-maven-3.6.1\bin\..
Java version: 1.8.0_221, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_221\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Also 'mvn -V clean test' using:

Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T15:00:29-04:00)
Maven home: C:\Java\apache-maven-3.6.1\bin\..
Java version: 1.7.0_80, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.7.0_80\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"

Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T15:00:29-04:00)
Maven home: C:\Java\apache-maven-3.6.1\bin\..
Java version: 11.0.4, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk-11.0.4
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T15:00:29-04:00)
Maven home: C:\Java\apache-maven-3.6.1\bin\..
Java version: 12.0.1, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\openjdk\jdk-12.0.1
Default locale: 

Re: [VOTE] Release Apache Commons VFS Project 2.4 based on RC1

[Pascal Schumacher]

+1

Am 16.07.2019 um 17:13 schrieb Otto Fowler:

+1 thanks Gary for keeping the VFS momentum up.




On July 16, 2019 at 07:20:20, Gary Gregory (garydgreg...@gmail.com) wrote:

May we have more (binding) VOTE(s) please?

Gary

On Fri, Jul 12, 2019, 12:27 Gary Gregory  wrote:


We have fixed quite a few bugs and added some significant enhancements
since Apache Commons VFS Project 2.3 was released, so I would like to
release Apache Commons VFS Project 2.4.

Apache Commons VFS Project 2.4 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/vfs/2.4-RC1 (svn
revision 34865)

The Git tag commons-vfs-2.4-RC1 commit for this RC is
796408d2f8423e22edc750b3f95ec6611b980704 which you can browse here:



https://gitbox.apache.org/repos/asf?p=commons-vfs.git;a=commit;h=796408d2f8423e22edc750b3f95ec6611b980704

You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-vfs.git
--branch commons-vfs-2.4-RC1 commons-vfs-2.4-RC1

Maven artifacts are here:



https://repository.apache.org/content/repositories/orgapachecommons-1447/org/apache/commons/commons-vfs2-project/2.4/

These are the artifacts and their SHA-512 hashes on
https://dist.apache.org/repos/dist/dev/commons/vfs/2.4-RC1:

commons-vfs-2.4-bin.tar.gz


b4bc9277c00ebaf0c8fe6534165b232db0766b9276709994d6b16e826c2531440c50261035fc40dbf48d0da0a90147ca094a3895b62577b7ee1018cab05419f6


commons-vfs-2.4-bin.zip


45c25d7d0b9ab30353d377e0fa80b55fc5eb5c228d43505635e17d3d43d3de0fd1521a5af2f9ebe669571fbbe5ff1aa863c4cad528a4b56e6cfa81c2e6112a65


commons-vfs-2.4-src.tar.gz


ba8011b1779fae7202d22dee24c6ab94b751739e932499a0230c7764b57d80427341b17841ac7dff298fb1ee321aa974223362313413e8d5d76d98e4b214


commons-vfs-2.4-src.zip


938d16546db0130316cb7b28872253c90dedc5c4b400ee5b50021dd4889bfcae9c09d52d355c2868bbd70c8486496737f1458841c5f24485f11f41485669


The following artifacts have been staged in Nexus:




/org/apache/commons/commons-vfs2-distribution/2.4/commons-vfs2-distribution-2.4-javadoc.jar.asc


(SHA1: 3be32ff790c0785b20f2b6ff2c1d2eb1b046a3ef)



/org/apache/commons/commons-vfs2-distribution/2.4/commons-vfs2-distribution-2.4-javadoc.jar


(SHA1: 592efe7f1e778fc5d3a2332b052d2be7822d405f)



/org/apache/commons/commons-vfs2-distribution/2.4/commons-vfs2-distribution-2.4.pom


(SHA1: f05651107067d2995e339c9ad49de3af9ad3af5b)



/org/apache/commons/commons-vfs2-distribution/2.4/commons-vfs2-distribution-2.4.pom.asc


(SHA1: c15fb439ae5155979521acac99b08a3b98b66e1a)
/org/apache/commons/commons-vfs2/2.4/commons-vfs2-2.4-test-sources.jar
(SHA1: 2cae50abccee652cb3637136ff0d28e7fece0795)


/org/apache/commons/commons-vfs2/2.4/commons-vfs2-2.4-test-sources.jar.asc

(SHA1: 7de44b57140d9a52a66f1645ea427fbdbfefdd11)
/org/apache/commons/commons-vfs2/2.4/commons-vfs2-2.4.jar
(SHA1: 085e8f1fc37279c89c1504393a4a748159d91046)
/org/apache/commons/commons-vfs2/2.4/commons-vfs2-2.4-javadoc.jar.asc
(SHA1: 00521b3fa061ac8ba6cc739f4fc895f82aec)
/org/apache/commons/commons-vfs2/2.4/commons-vfs2-2.4.pom
(SHA1: bafc6da7a594ab33222c70cc67788a2fa1b63ffa)
/org/apache/commons/commons-vfs2/2.4/commons-vfs2-2.4-javadoc.jar
(SHA1: 06b4e4f58e9c5a7e609c74ba1e8a6e311f56f8c4)
/org/apache/commons/commons-vfs2/2.4/commons-vfs2-2.4-sources.jar.asc
(SHA1: dab139a477b22ebddcdf16bd79c2d3fa18f79832)
/org/apache/commons/commons-vfs2/2.4/commons-vfs2-2.4.pom.asc
(SHA1: 891a6e8eec524b0ef2a41e83bd2955a16aecc914)
/org/apache/commons/commons-vfs2/2.4/commons-vfs2-2.4-sources.jar
(SHA1: afa50c0895aa002adb7c0c5614d9885abd70fb2a)
/org/apache/commons/commons-vfs2/2.4/commons-vfs2-2.4-tests.jar
(SHA1: 3b4f76fb2c9c0b1e5c8c00715e271e6c7514e825)
/org/apache/commons/commons-vfs2/2.4/commons-vfs2-2.4.jar.asc
(SHA1: 94cc44bc43ba99f3b771ca6f5e9249a5923f344e)
/org/apache/commons/commons-vfs2/2.4/commons-vfs2-2.4-tests.jar.asc
(SHA1: 0466ac93c8eec703e2ae1b7fb6db76159872e19f)



/org/apache/commons/commons-vfs2-project/2.4/commons-vfs2-project-2.4.pom.asc


(SHA1: 18b9b81a9a1e55495d746c11f90b6c11b35e9bfa)
/org/apache/commons/commons-vfs2-project/2.4/commons-vfs2-project-2.4.pom
(SHA1: 17c963b66f27497a36618c851ccbee8b3006f9ea)



/org/apache/commons/commons-vfs2-project/2.4/commons-vfs2-project-2.4-site.xml.asc


(SHA1: 713c993dc4342b36c1c3c5243369b485e069693f)



/org/apache/commons/commons-vfs2-project/2.4/commons-vfs2-project-2.4-site.xml


(SHA1: baca67a9f6be69b52869c2ec49b7487bdbd6bc9f)



/org/apache/commons/commons-vfs2-project/2.4/commons-vfs2-project-2.4-javadoc.jar


(SHA1: 22a19ca2c9d4ad2f3fb5179c5f058a4216e71d2e)



/org/apache/commons/commons-vfs2-project/2.4/commons-vfs2-project-2.4-javadoc.jar.asc


(SHA1: 032892276f7814b6a51a0e231450450a3d710cab)


/org/apache/commons/commons-vfs2-examples/2.4/commons-vfs2-examples-2.4.jar

(SHA1: 01a8b92efa47e9ff54800bb4626d1907f6134bc1)



/org/apache/commons/commons-vfs2-examples/2.4/commons-vfs2-examples-2.4-sources.jar


(SHA1: b070600f9ed7d51b9bb24dd9a3b68a121e9ab188)

Re: [VOTE] Release Apache Commons Text 1.7 based on RC1

[Pascal Schumacher]

+ 1

Am 30. Juni 2019 16:28:45 MESZ schrieb Gary Gregory :
>We have fixed quite a few bugs and added some significant enhancements
>since Apache Commons Text 1.6 was released, so I would like to release
>Apache Commons Text 1.7.
>
>Apache Commons Text 1.7 RC1 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/text/1.7-RC1 (svn
>revision 34703)
>
>The Git tag commons-text-1.7-RC1 commit for this RC is
>3866d2626dc3767b003c7cfe163a388b10c80957 which you can browse here:
>
>https://gitbox.apache.org/repos/asf?p=commons-text.git;a=commit;h=3866d2626dc3767b003c7cfe163a388b10c80957
>You may checkout this tag using:
>git clone https://gitbox.apache.org/repos/asf/commons-text.git --branch
>commons-text-1.7-RC1 commons-text-1.7-RC1
>
>Maven artifacts are here:
>
>https://repository.apache.org/content/repositories/orgapachecommons-1445/org/apache/commons/commons-text/1.7/
>
>These are the artifacts and their hashes:
>
>#Release SHA-512s
>#Sun Jun 30 10:15:20 EDT 2019
>commons-text-1.7-bin.tar.gz=b900c07380f986c916e8fba6bff561ddf5bd1362d8b7b4b4487a780cb78ba86fc3cf0b30fc6b07053fca26a893ada44134fc2d0ab31bee6394e44f411ad3cdb4
>commons-text-1.7-bin.tar.gz.asc=0b5d581f3c085ae428ef2c149c74127d9a1070f5ea2cdfe8394446cc6b2481ea712d07b3a65fb455bfbb991027138dc633b3845a083041b5b8f8d295080a3ab0
>commons-text-1.7-bin.zip=d97c7021c568b349a4ae09f5fcfae3a6ce592aec83b46f7c9c9777c945e3555a25e93ef39544eb4430ee00206aca2979e35542709d23461f0229c2df80744234
>commons-text-1.7-bin.zip.asc=a861e9786b00fec6c39ea6705e388c3b08225a8f5fc399c2f68d09b6d61b60fd16337731d71013e8eccb178b7d6c4c53bfdec5363139bf9bd42d7605b8b21c15
>commons-text-1.7-javadoc.jar=138588633e95974fadca17340ec771e1bea8a614e53ec37aaa9b86fc4a09ee3bfc2645f207ff2fa9c4c53c664ee767d14a6a683145d0165ff94f5e1d4b8d7a14
>commons-text-1.7-javadoc.jar.asc=7fc209412ced402547eade377a3e184572a503b11cdccde3c043023601f351f26235b56fd94ad00158e25c5e1a8d0055e7e8e88a5cb0d0448cddd2f0da054a73
>commons-text-1.7-sources.jar=380158e7aa99be61608dd53b7929e48cc4d4f4e898221033205d36b22f6d59046f67fceaa1df832ca3f6760515980a5df4b9c450ced43e4aa9ee26fab22baaa7
>commons-text-1.7-sources.jar.asc=1db512a3af2ad5c04617dcf896e611bee7a029ec51b9892bea02504fc283212b4d6d3c44af703d31a3802e5bf4f5fb537d455d50b070aa4e4b0ffe4902c381d5
>commons-text-1.7-src.tar.gz=5660e4566e55b42e3b6ca22cd50affa232f5477e9ac30bd244eea7cdedc7f588d633e54aeb52bdec77506a8cbab22124b8c2fd6a94901140df75a75751775106
>commons-text-1.7-src.tar.gz.asc=fa3486f6f0ed1521875a4a4e41028e10680149440fa1c9ea9960cc8cb3cca5ce3ceaad41336ac8bf62b100c187a7b9ed4608d84230f57a33e66ecc1fa9464a64
>commons-text-1.7-src.zip=e168f84b109a2d174e6c51ce3a94606e00a2ac1373a88486e9dca735133e3a1f3e906b580e59f1aa38d9dd2f31774dba9f5d1a0b402db3fd87d9aa36438d713b
>commons-text-1.7-src.zip.asc=81a06410fbb81055b8580b4b7a9d635b8f5ccc851419aa23346e87f67578d09b8cc16637713bb4595998086651b7256400af3b134db5bbbea8b6255b4afe8438
>commons-text-1.7-test-sources.jar=d2ead377bfc1f57efb4f885764b47e956b702063147c550dbc71789681654612aec69d0d585f5afac52a3b650e4c72189f68f6eef3b3e06427dc53ff0f58ff20
>commons-text-1.7-test-sources.jar.asc=1e9e481115338f1213ddacdaaebfbbc611c7cfe9816b0f432ea143fee2777e8a19b5bc987e1438a97b9b9a7afc1fe01188be7b055494c47bede93c1e366ee37a
>commons-text-1.7-tests.jar=b6109fee5d299cd0d0985938b65703b7b1941995d00eeb169d98de18c1eabbaff7feeb258bab819e5a6a4dc06a9647235b900b2bd2457296810e2fabf64b
>commons-text-1.7-tests.jar.asc=2f6297a03538e6b128e505aab34cce75790e9256c6545e964ee3918eac88dfb69d2fddaa845242022a55354b9a6911e207a190f8b81b7e6e6d19eeb986096511
>commons-text-1.7.jar.asc=566460a04edb42c34a7d5bda1b255804a61a134a08ae881af6a1b3476ca178da1bc27f2900776785a4a2af8fc7cec74935791e354e1b91885e356e3873172aa0
>commons-text-1.7.pom.asc=d481dd4360ca514b9279b5e38780f65b33555cc07c927f761e5ca1df1d6e013ffb0390245d6ac5046cef77be0102465a133f9c4663eb14f0316f987033bd0074
>
>(no need for .asc hashes!)
>
>I have tested this with 'mvn -V -Duser.name=%my_apache_id%
>-Dcommons.release-plugin.version=%commons.release-plugin.version%
>-Ddoclint=none -Prelease -Pjacoco -Ptest-deploy clean package site
>deploy'
>using:
>
>Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
>2019-04-04T15:00:29-04:00)
>Maven home: C:\Java\apache-maven-3.6.1\bin\..
>Java version: 1.8.0_212, vendor: Oracle Corporation, runtime:
>C:\Program
>Files\Java\jdk1.8.0_212\jre
>Default locale: en_US, platform encoding: Cp1252
>OS name: "windows 10", version: "10.0", arch: "amd64", family:
>"windows"
>
>After the above, I ran 'mvn -V test' with:
>
>Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
>2019-04-04T15:00:29-04:00)
>Maven home: C:\Java\apache-maven-3.6.1\bin\..
>Java version: 11.0.3, vendor: Oracle Corporation, runtime: C:\Program
>Files\Java\jdk-11.0.3
>Default locale: en_US, platform encoding: Cp1252
>OS name: "windows 10", version: "10.0", arch: "amd64", family:
>"windows"
>
>Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
>2019-04-04T15:00:29-04:00)
>Maven home: 

Re: [git] please avoid force pushes

[Pascal Schumacher]

Am 13.06.2019 um 19:29 schrieb Eric Barnhill:

Apologies if everyone knows this but...

There has been some force pushing in the git repos lately. Unfortunately
there are a lot of Stack Overflow answers that will tell the user to solve
a complex commit situation by force pushing. These answers are just
*wrong*. By the nature of our code it is being used by more than one
pseron, and therefore force pushing should never happen. There is always a
better way.

+1

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

Re: Is there some plans for implementing some primitive datas tructures?

[Pascal Schumacher]

Am 07.06.2019 um 21:53 schrieb Xeno Amess:

1.  Is this thing done by some libraries before?

Not Apache, but two popular open collection libraries offering primitive
collections are trove4j (https://bitbucket.org/trove4j) and Eclipse
Collections (https://www.eclipse.org/collections/).

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

Re: [codec] Java 8

[Pascal Schumacher]

Am 22. März 2019 19:56:29 MEZ schrieb Gary Gregory :
>On Fri, Mar 22, 2019 at 2:53 PM sebb  wrote:
>
>> I see no reason to update to Java 8 unless continuing with Java 7
>> becomes a big hassle.
>>
>> Why penalise people stuck on Java 7 unnecessarily?
>>
>
>I see it the other way around: Why do we want to handcuff new
>development
>on a dead platforms? For new contributors, this is a huge turn off.

+1


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

Re: [Parent] RAT check

[Pascal Schumacher]

+1

Am 09.03.2019 um 23:44 schrieb Gary Gregory:

Hi all:

How about making apache-rat:check run automatically in commons-parent? In
the Maven validate phase?

That would mean one less thing to check when integrating a patch and
validating an RC.

Gary




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

Re: [VOTE] Redirect github notifications to issues@

[Pascal Schumacher]

Thank you very much!

Am 04.03.2019 um 18:25 schrieb Marcelo Vanzin:

FYI, it should all be done now, so if you want to get notifications,
either sign up to issues@, or watch the repo on github.

On Fri, Feb 22, 2019 at 9:49 AM Marcelo Vanzin  wrote:

Jira link: https://issues.apache.org/jira/browse/INFRA-17892

On Fri, Feb 22, 2019 at 9:44 AM Marcelo Vanzin  wrote:

Thanks all, vote passes with 11 +1s, no -1s.

I'll file the INFRA ticket and link it back here soon.

On Tue, Feb 19, 2019 at 1:35 PM Marcelo Vanzin  wrote:

I'm opening a vote based on recent discussions about the extra noise
generated by github updates going to dev@. So please vote:

- +1 to redirect github updates of all commons repos to the issues@ list
- -1 to keep things as is

If the vote passes, I'll take care of opening an infra ticket
referencing the result.

--
Marcelo



--
Marcelo



--
Marcelo






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

Re: [LANG] Jenkins Pipeline DSL

[Pascal Schumacher]

Am 03.03.2019 um 14:56 schrieb sebb:

For example, what about notifications for failed builds - is that
maintained in Jenkins or in the pipeline file?


Notification can be defined in the pipeline.

Pretty much everything can be defined in a jenkins file nowadays (some 
plugins do not have pipeline support (yet)).


https://jenkins.io/doc/book/pipeline/ has a lot of useful information.


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

Re: [ALL][RFC] Github subjects don't contain the repo name

[Pascal Schumacher]

Am 01.03.2019 um 22:53 schrieb Mark Thomas:

Why not
[commons-io] zsoltii opened a new pull request #74: Add new function:
byteCountToDisplayRoundedSize

to match the format of the commit messages? And to make the subject a
little shorter.

+1

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

Re: [VOTE] Redirect github notifications to issues@

[Pascal Schumacher]

Thank you very much for taking care of this!

Am 22.02.2019 um 18:49 schrieb Marcelo Vanzin:

Jira link: https://issues.apache.org/jira/browse/INFRA-17892

On Fri, Feb 22, 2019 at 9:44 AM Marcelo Vanzin  wrote:

Thanks all, vote passes with 11 +1s, no -1s.

I'll file the INFRA ticket and link it back here soon.

On Tue, Feb 19, 2019 at 1:35 PM Marcelo Vanzin  wrote:

I'm opening a vote based on recent discussions about the extra noise
generated by github updates going to dev@. So please vote:

- +1 to redirect github updates of all commons repos to the issues@ list
- -1 to keep things as is

If the vote passes, I'll take care of opening an infra ticket
referencing the result.

--
Marcelo



--
Marcelo






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

Github notification and Jira Issues (was: Re: [VOTE] Redirect github notifications to issues@)

[Pascal Schumacher]

Am 20.02.2019 um 19:39 schrieb Marcelo Vanzin:

Rob:

I almost think that we should have Pull Requests generate jiras.

I've seen this set up in a couple of projects and jira becomes
unreadable... the updates generated by github are horrible to read. I
really don't like them.


Imho the way to make it really easy to contribute and raise issues is to 
use github issues instead of jira. A lot of people already have a github 
account nowadays. Github issues are indexed by search engines (Apache 
Jira is not). Contributors do not have to create a jira issue and a pull 
request for code contributions.


Other Apache Projects are already using gitub issues (e.g. 
https://github.com/apache/bookkeeper).


Spring Framework recently migrated from Jira to github issues and wrote 
about it in detail: 
https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues


Just my two cents,

Pascal




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

Re: [text] TEXT-104 clirr errors, prepare 2.0 or revert change

[Pascal Schumacher]

I'm fine with either solution, but my preference would be to remove all 
deprecated stuff and release version 2.0.


Am 20.02.2019 um 08:42 schrieb Bruno P. Kinoshita:

Hi all,
Just finished merging a pull request to TEXT-104, where the JaroWinkler 
distance was updated. The class was actually computing a text similarity score, 
not an edit distance. The user that contributed did a great job moving the 
logic into a separate class, then updating the method to return a distance 
instead.
Later I realized this would break both behaviour and binary compatibility.
So just wondering what others think. Is it time to gather a few more issues in 
text, maybe even consider updating libraries/java/etc, drop @Deprecated stuff, 
and prepare a 2.0? Or is it too soon, and instead revert moving the code to a 
branch, and update TEXT-104 with a note about the branch?
CheersBruno




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

Re: [VOTE] Redirect github notifications to issues@

[Pascal Schumacher]

+1

Am 19.02.2019 um 22:35 schrieb Marcelo Vanzin:

I'm opening a vote based on recent discussions about the extra noise
generated by github updates going to dev@. So please vote:

- +1 to redirect github updates of all commons repos to the issues@ list
- -1 to keep things as is

If the vote passes, I'll take care of opening an infra ticket
referencing the result.




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

Re: [LANG] Jenkins Pipeline DSL

[Pascal Schumacher]

+1 to using a pipeline

Am 17.02.2019 um 18:35 schrieb Benedikt Ritter:

Hi all,

I feel like maintaining separate build descriptions on Jenkins is a PITA.
Any objections against adopting Jenkins Pipeline DSL for Lang?

Regards,
Benedikt




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

Re: [DISCUSS] Change github notifications for all commons sub-projects

[Pascal Schumacher]

+1 for moving github notifications to issues@

Am 15.02.2019 um 20:02 schrieb Marcelo Vanzin:

Hey all,

There was a recent thread ([1]) with a brief discussion about the
number of github updates that are currently ending up in the dev@
mailing list.

Personally I find that a little too noisy (especially since I get 2
e-mails for repos that I'm subscribed to), and it seems others also
don't like it very much.

So I'd like to throw out 3 different proposals to see what people
think. All 3 are used today by different repos, so this would also be
a proposal to make this consistent across all commons projects.

(1) Move all github notifications to issues@ (a la commons-lang)
(2) Move all github notifications to notifications@ (a la commons-numbers)
(3) Move all github notifications to dev@ (a la a bunch of others)

Another option would be to create a separate list for these, although
that's probably overkill.

I know I said I'd open an infra ticket for commons-crypto at least,
but not being in the PMC, I'm sure they'd have asked for PMC input.

Thanks!

[1] 
https://lists.apache.org/thread.html/d210cf6c008d30d5e0ce105dc5f54dfb1e65c7a8df98a88b509669fc@%3Cdev.commons.apache.org%3E




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

Re: [RNG, ALL] Checkstyle version

[Pascal Schumacher]

Am 11.02.2019 um 22:15 schrieb sebb:

Aren't there different profiles for different Java versions?
There was at least one plugin which needed different versions, so
maybe take the same approach here.

It's a bit more work to set up the pom, but it saves a lot of work
downstream fixing component poms and/or answering complaints that the
build fails ...

+1, good idea

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

Re: [RNG, ALL] Checkstyle version

[Pascal Schumacher]

Am 11.02.2019 um 12:19 schrieb Alex Herbert:
I would like to upgrade the checkstyle version in commons-rng. 
Currently the project uses maven-checkstyle-plugin 3.0.0 which 
defaults to checkstyle 6.18.


This version is old [1] and not supported by modern IDEs. An update 
(to version 8.x) would allow checkstyle to be run within the IDE and 
avoid separate checks of the checkstyle report on the command line.


There is no management of the checkstyle version in commons-parent. I 
would like to get a consensus on the versions used across commons and 
any reason to not upgrade. There may be legacy reasons I am unaware of.


Checkstyle 7+ requires Java 8 and not that long ago (almost) all commons 
projects required only Java 7 or less.


Imho commons-parent can use the most recent check-style version (8.17). 
Of course this would force projects which use Java 7 or less to override 
the checkstyle version when they update to the latest commons-parent 
version.




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

Re: [ALL] Broken builds

[Pascal Schumacher]

I'm not sure if the error can be fixed in the Maven Javadoc Plugin.

While the bug was rejected by OpenJDK at first, is was later reopened 
and fixed, but only in Java 13 and 12.0.1:


https://bugs.openjdk.java.net/browse/JDK-8212233

Am 10.02.2019 um 14:24 schrieb Gary Gregory:

Note that builds that break on Java 11 due to Javadoc errors with unnamed
modules _should_ be fixed when the next version of the Maven Javadoc Plugin
is released (3.1.0 IIRC)

Gary

On Sat, Feb 9, 2019 at 11:56 AM Gilles Sadowski 
wrote:


Hi.

Le sam. 9 févr. 2019 à 17:10, Benedikt Ritter  a
écrit :

Hi,

several component have are broken builds on the master branch. Should be
change our policy for pushing to master to a pull request based model,
where each change has to pass the CI pipeline first? I think this would

be

better as pushing stuff to master and then fixing it afterwards.

One thing to take into account is that some CI jobs break for "unknown"
reasons (e.g. due to new requirements by Jenkins).  Few people looking
into these issues leads to builds staying broken for extended period of
times; it would quite annoying that pushing is prevented even though
local builds continue to work as usual.

Gilles


Benedikt

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





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

Re: [VFS] Tests fail on Java 11

[Pascal Schumacher]

Just a guess, but

Caused by: javax.net.ssl.SSLHandshakeException: No available 
authentication scheme


seems to hint at TLS  version / cypher suite changes. The antique 
versions probably want to use a cypher suite that is disabled on Java 
11, e.g. 3DES


https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html#JDK-8175075

For more details see:

https://java.com/en/jre-jdk-cryptoroadmap.html

https://www.java.com/en/configure_crypto.html

Am 04.02.2019 um 23:29 schrieb Gary Gregory:

Now that 2.3 is done, I'd like some help to get the build running on Java
11, which currently fails in the tests:

https://travis-ci.org/apache/commons-vfs/jobs/488728611

The failures might all be related to the antique version of Apache Mina and
JackRabbit we are using.

Does anyone have the knowledge to help here?

Thank you,
Gary

Re: [VOTE] Release Apache Commons VFS 2.3 based on RC2

[Pascal Schumacher]

+1

looks good

Am 04.02.2019 um 17:00 schrieb Rob Tompkins:

+1

signatures, rat, (minor nits) checkstyle issues, (minor nits) findbugs issues.

I had a build issue with java11 that looks insurmountable for this release. 
Specifically:

Tests in error:
   
AbstractFtpsProviderTestCase$FtpProviderTestSuite>AbstractTestSuite.run:137->setUp:153->AbstractTestSuite.setUp:166
 » FileSystem
   
AbstractFtpsProviderTestCase$FtpProviderTestSuite>AbstractTestSuite.run:137->setUp:153->AbstractTestSuite.setUp:166
 » FileSystem
   MultipleConnectionTestCase.testConnectRoot:55->resolveRoot:49 » FileSystem 
Cou...
   MultipleConnectionTestCase.testUnderlyingConnect:65 » SSL Unsupported or 
unrec...

Tests run: 2447, Failures: 0, Errors: 4, Skipped: 4

[INFO] 
[INFO] Reactor Summary for Apache Commons VFS Project 2.3:
[INFO]
[INFO] Apache Commons VFS Project . SUCCESS [ 25.783 s]
[INFO] Apache Commons VFS . FAILURE [03:14 min]
[INFO] Apache Commons VFS Examples  SKIPPED
[INFO] Apache Commons VFS Distribution  SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  03:40 min
[INFO] Finished at: 2019-02-04T09:52:35-05:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on 
project commons-vfs2: There are test failures.
[ERROR]
[ERROR] Please refer to 
/Users/tompkicr/Desktop/vfs/2.3-RC2/source/commons-vfs-2.3/commons-vfs2/target/surefire-reports
 for the individual test results.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :commons-vfs2
MacBook-Pro:commons-vfs-2.3 tompkicr$ mvn -version
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T14:41:47-04:00)
Maven home: /usr/local/Cellar/maven/3.6.0/libexec
Java version: 11.0.2, vendor: Oracle Corporation, runtime: 
/Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.3", arch: "x86_64", family: “mac"




On Feb 1, 2019, at 12:36 PM, Gary Gregory  wrote:

We have fixed quite a few bugs and added some significant enhancements
since Apache Commons VFS Distribution 2.2 was released, so I would like to
release Apache Commons VFS Distribution 2.3.

Apache Commons VFS Distribution 2.3 RC2 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/vfs/2.3-RC2 (svn
revision 32298)

The Git tag commons-vfs-project-2.3-RC2 commit for this RC is
a52627eaf1a45190649de6a912d678a16a976707

https://gitbox.apache.org/repos/asf?p=commons-vfs.git;a=tag;h=refs/tags/commons-vfs2-project-2.3-RC2

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1417/org/apache/commons/commons-vfs2-distribution/2.3/

These are the Maven artifacts and their hashes in Nexus:

#Release SHA-512s
#Fri Feb 01 12:17:36 EST 2019
commons-vfs2-distribution-2.3-src-zip.asc=c4aa9a73347490cc8f1c6500ad6c7a62e4e8847ca6f4edb0b4b94073ad4bc9aff9f224400ffa4e3ba712babd8190d006a90f7ef188929289f9b9fe35ea7e9c39
commons-vfs2-distribution-2.3-pom.asc=dcb82e91e452d02838bd9a2cbf7340743eeb5e1149e494c972c5023798a1492f09aa17b969f2066881296ed3a4895b55af2091a1651453db525ce1b20569c927
commons-vfs2-distribution-2.3-bin-zip=1c1ee0f5916a87557ab45103de39022589ac7f95319dacfb4d644c0e5349c39d5faa0a00e71e16f385609bf66164d389db3e584b76b71bdd54246283c1ae4c79
commons-vfs2-distribution-2.3-bin-tar.gz=d64024841170c91b11aa12daee145afe9975e8bcf219b3a12ccc2eaa5e13d82b49346584f5221912c5e51b9e923ddea2709a1782e7a4839d43d0c52ef4fb4173
commons-vfs2-distribution-2.3-bin-tar.gz.asc=5c14d28544d22c8bb246e7b8e110e145232d22bdbd8db24ad689484bd004250c74bc3e3b9d0e1a929180d39d94445a73b6ac37d4b98eb181a1a9f97baf07b91e
commons-vfs2-distribution-2.3-src-zip=60f2cfb8eb38a5b6b0137b69f4358fed64a2d2f7a89aaf1622d4198adcfe3b18947cf0b182578dde30de4a2bbc3b0fef79b11b6f0fd7ef5e43b96e6aeafa7f34
commons-vfs2-distribution-2.3-bin-zip.asc=0c2b6cd5e76713ceaaba951bd1e52c6ee1cd756434c215f80521b69613df3531109ba86677c2484c78448e44e3b190e4f5a13ee7b397e41703f61384fc1138c5

Re: [lang] Ready for 3.9???

[Pascal Schumacher]

No sure if it worth it, as there are very few new features and no 
bugfixes, see:


https://github.com/apache/commons-lang/blob/master/src/changes/changes.xml

Also the function class addition:

https://github.com/apache/commons-lang/commit/11d9eb47a40359e74a5e24daf681beacd71b35f0 



https://github.com/apache/commons-lang/commit/2ebc17ba3f244ae44aae46273aeef7e321f9542a 



broke the build, because:

- FunctionsTest is missing the apache license header

- Functions and FunctionsTest contain check-style violation

Am 02.02.2019 um 21:49 schrieb Rob Tompkins:

Just curious if we want to send 3.9 out? Build on java 11 targeting java 8?

-Rob

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




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

Re: [ANNOUNCE] Commons Release Plugin 1.5 released.

[Pascal Schumacher]

+1

Am 01.02.2019 um 03:13 schrieb Gary Gregory:

Thank you Rob!

Gary

On Wed, Jan 30, 2019 at 9:21 AM Rob Tompkins  wrote:


[This announcement is only going to the dev list.]

The Apache Commons Release Plugin team is pleased to announce the release
of
Apache
Commons Release Plugin 1.5.

The Apache Commons Release Plugin is a collection of Java based Maven
mojos for
Apache Commons
Release process. These mojos are intended to be used as a collection of
steps to
be strung
together for the purpose of removing the manual steps required to produce
an
Apache Commons Release.

List of changes:
http://commons.apache.org/commons-release-plugin/changes-report.html <
http://commons.apache.org/commons-release-plugin/changes-report.html>

For complete information on Apache Commons Release Plugin, including
instructions
on how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons
Release Plugin website:

http://commons.apache.org/commons-release-plugin/index.html <
http://commons.apache.org/commons-release-plugin/index.html>

Cheers,
-Rob




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

Re: [LANG] Checked Functions PR

[Pascal Schumacher]

Am 30.01.2019 um 20:27 schrieb Jochen Wiedmann:

Have you seen [1]?

1: 
https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=blob_plain;f=src/main/java/org/apache/commons/lang3/Functions.java;h=5eaed0c6fa8dbb8ed7a2ba37d499130ba62f138b;hb=HEAD


By the way:

https://github.com/apache/commons-lang/commit/11d9eb47a40359e74a5e24daf681beacd71b35f0

https://github.com/apache/commons-lang/commit/2ebc17ba3f244ae44aae46273aeef7e321f9542a

break the (travis-ci) build, because:

- FunctionsTest is missing the apache license header

- Functions and FunctionsTest contain check-style violations

Please run `mvn` and fix the issues reported.

Thanks,

Pascal





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

Re: JAPICMP Collections-4.3-RC2 report pdf (Was: Re: [VOTE][RC2] Commons collections 4.3)

[Pascal Schumacher]

Am 28.01.2019 um 20:01 schrieb Rob Tompkins:

Before I vote on the the thread, does adding a method to an interface cause BC 
to break?


"Adding a method to an interface does not break compatibility with 
pre-existing binaries."


Source: 
https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.5.1



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

Re: [VOTE] Release Apache Commons BCEL 6.3 based on RC1

[Pascal Schumacher]

+1

Am 27.01.2019 um 16:06 schrieb Rob Tompkins:

+1
signatures good, sha1 (nexus), md5 (nexus), sha512, asc

builds in java8 and java11

Issue: RELEASE-NOTES.txt has 6.3-SNAPSHOT not 6.3 in it (Fixable)

Nits:
checkstyle, pmd, cpd, findbugs few issues.

———
Aside: I will try to get to the collections-4.3 [VOTE] before the end of the day



On Jan 24, 2019, at 4:19 PM, Gary Gregory  wrote:

We have fixed quite a few bugs and added some significant enhancements
since Apache Commons BCEL 6.2 was released, so I would like to release
Apache Commons BCEL 6.3.

Apache Commons BCEL 6.3 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/bcel/6.3-RC1 (svn
revision 32125)

The Subversion tag for this RC is here:
https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_3_RC1/
(svn revision 1852073)
N.B. the SVN revision is required because SVN tags are not immutable.

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1410/org/apache/bcel/bcel/6.3/

These are the Maven artifacts and their hashes in Nexus:

${commons.sha256list}
#Release SHA-512s
#Thu Jan 24 15:38:52 EST 2019
bcel-6.3-javadoc-javadoc=91dd316818395e937cd86584d1fc55bf2e392a5b08225aab691c8e34821d56fbcd0c31036dcea00f7b4ce78429e2f69443c396f946eee571cb012ca023f2bec7
bcel-6.3-src-tar.gz.asc=04bbed23cc3f64401d6495ecb8e08d068dc9a28d06b3f2965b1d190c550db97683949d5a64a1050d7cecb24fd6b650080b0dcdfe45849c52fb98b39ed651ba5d
bcel-6.3-src-zip.asc=458ee35da2f2d7cec7c7ec9745fbcec4f3c5db366691779fa6ae5ca950b622a73689f373719e5756f89a46d2de82c57187a62e7b8722d100a641aae76623f14f
bcel-6.3-bin-zip.asc=75ff4a83785d4134b6f516d2adcc9d3678fa18d8f209c1f302d089b0a977f937339cf387e6b742b716963855eaa347473f1b96e19c288a70060939d18f542189
bcel-6.3-src-tar.gz=358377437a2f667484deca3cf2f3f189ceaaf830dd8a04586047d1a057cd1f3cacc7cb6beaab363c2c7914608b4566cba355790c7b031e5502cd71d5047cb102
bcel-6.3-tests-test-jar=c5176022291e622b55ad2f2b656c14169d8c7dcf7c19548322da544fc65440032d5a04805032bbf084feaf17ce81807cd91c3b9fabecb345776051892a47a64c
bcel-6.3-tests-jar.asc=533006b11a6bd196d29d8edf1e89e718ed06be922b80ea93a624295851a818ebef0a1f83ed36efaf66cde98cd2201a93e707dfb468666f6ee1b2d0938d4e29be
bcel-6.3-bin-zip=664f7d6b55f00b0f3a7bc8851da8f82dba4c077c32fdc1933dedad9662f5c9daf083d9e92e703fb6b89cd3f9c998fdf64fd3cba70f5d30bbc703af2dd8856734
bcel-6.3-sources-jar.asc=c912eeff39eee81a3b8cdb3c610aefa4ede08719688996b93c618571056daa70f4f7b4730177d320ddd257bb855f83452d218077d9d806700df164f1bc90dd89
bcel-6.3-bin-tar.gz=6461c1dfa27ead22ba7463ff2fbc1b385fbb46c48465cb4bb4a158a98f6fce3396efd48222e523862e5a7af3993ee777013498e05c5ff4125b8aa02317d434c2
bcel-6.3-test-sources-jar.asc=323f43172b68f96c47f101a3f510f93170d5ca7d5c49b8e0d4dd8926e79818a8caf86697f31d24c4589d1204816a90454aba68f49a90017f47ecb50651f1d1c4
bcel-6.3-test-sources-java-source=7879894ea7e9b5cd0318de41b1fd45511787935588a04a95ebcf04adccdf60bd981744919698379ea15fc7bc2398e7605a5766e70e1affa9af47959dabf3e121
bcel-6.3-pom.asc=25a7f4b9371130e85436831f122ccf2ebf8e98f9440060c0e7efe884346565dc563c7fccd91b9b24bfad0c8a359ec1ecc541edaaa3dac111578bcf4005782ff2
bcel-6.3-javadoc-jar.asc=32c951bf4347858b9b4d863118e9a3753584519eee89ff035cbb883a010d8333eca2d8c18aacf21bebbcb94ebf66e8dbab873ee7242fb5d2bc7a1a0d24da
bcel-6.3-jar.asc=dc43ed9c2c2d2cb10fd9a2af9053120018a96bc68422905dc7e0426082bf60396d9bb646fb879801a0b2c7d98aea5cfe8579b27b684f78608b3348ea807ccc79
bcel-6.3-sources-java-source=b8b5d2590334730582c9dd93e28d4636fda9ac47ad34816d7ab8e4a771ac61e1b20b8c14208409d0652c6f8a2b63c4155295ddbee56e21273792267f9c7357ff
bcel-6.3-bin-tar.gz.asc=2e4d8283567f5518270da83d9b0176da4325671d855bf05073bdf5c6feaa4e43653c49cad0aec0dbcc4e01b5605bf47c5508531dce4a70f61f5e8c81c6cffe97
bcel-6.3-src-zip=18a4caa594b37e8aae3c5a095260f9d3b04df5bcbfdcbe8a43feb15a7a4d2b9ea834331bd93ca8d461e7f791c390262fbca788bb4ee70d7bde4e7f85ea34bdee

(no need for .asc hashes!)

I have tested this with 'mvn -Ddoclint=none clean package site' using:

Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T14:41:47-04:00)
Maven home: C:\Java\apache-maven-3.6.0\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_202\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Details of changes since 6.2 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.3-RC1/RELEASE-NOTES.txt

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

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

CLIRR Report (compared to 6.2):

https://dist.apache.org/repos/dist/dev/commons/bcel/6.3-RC1/site/clirr-report.html

Note that Clirr reports one errors:
Method 'public void

Re: [VOTE][LAZY] Move commons-codec to gitbox after 1.12 release.

[Pascal Schumacher]

+1

Am 28.12.2018 um 15:51 schrieb Rob Tompkins:

After doing the 1.12 release I propose we move commons-codec to gitbox. This is 
a [LAZY] consensus [VOTE] for doing such after I get through the release. This 
[LAZY][VOTE] will be open for at least 72 hours form now.

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




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

Re: [VOTE][LAZY] move commons git-wip repos to gitbox

[Pascal Schumacher]

+1

Am 08.12.2018 um 21:09 schrieb Rob Tompkins:

Infra stated that we need documented consensus on this. So, let’s have at it.

I propose that we move the following repos over to gitbox:

commons-build-plugin.git   11 weeks ago
commons-cli.git30 weeks ago
commons-collections.git15 days ago
commons-compress.git   19 days ago
commons-crypto.git  9 weeks ago
commons-csv.git 7 weeks ago
commons-dbcp.git   24 days ago
commons-dbutils.git30 weeks ago
commons-fileupload.git 29 weeks ago
commons-imaging.git 6 weeks ago
commons-io.git 18 days ago
commons-lang.git6 days ago
commons-math.git   15 weeks ago
commons-numbers.git 8 days ago
commons-pool.git   16 days ago
commons-rdf.git25 weeks ago
commons-release-plugin.git 25 days ago
commons-rng.git   < 2 days ago
commons-scxml.git   7 weeks ago
commons-statistics.git 30 weeks ago
commons-testing.git30 weeks ago
commons-text.git   14 days ago

This vote will close in 72 hours.

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




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

Re: [Lang] CheckedFunction#unchecked

[Pascal Schumacher]

Hi Aleksander,

thanks.

Imho this would be a useful addition to commons-lang.

Any other opinions?

Cheers,
Pascal

Am 21.11.2018 um 22:52 schrieb Aleksander Ściborek:

Hi
I've just created pull request
 for CheeckedFunction
interface. This is an example of utils I would like to add in order to
simplify usage of java Stream.
Aleksander




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

Re: [IO] Provenance of copied code in InfiniteCircularInputStream

[Pascal Schumacher]

Hi everybody,

the code is from a pull request which I merged:

https://github.com/apache/commons-io/pull/8

I did not author the code.

The comment seems incorrect because I do not think there is a field 
"repeatedContent" in java.io.ByteArrayInputStream. The current OpenJDK 
implementation looks pretty different:


http://hg.openjdk.java.net/jdk/jdk/file/49e0f711bb2b/src/java.base/share/classes/java/io/ByteArrayInputStream.java#l146

-Pascal

Am 19.11.2018 um 16:59 schrieb Gary Gregory:

Hi All and Pascal S.,

Sharon (Eclipse) has pointed out to me that 
in org.apache.commons.io.input.InfiniteCircularInputStream.read() [1], 
we have:


    @Override
    public int read() {
        position = (position + 1) % repeatedContent.length;
        return repeatedContent[position] & 0xff; // copied from
 // java.io.ByteArrayInputStream.read()
    }

Where does the code originate? Oracle JRE? OpenJDK? Where? Such a 
comment needs to show better provenance since I am pretty sure we are 
NOT allowed to copy code from Oracle.


The code was added with the commit

https://github.com/apache/commons-io/commit/699d6f0eca65837501d7ab7a92ae2c614f8e6cbf#diff-5cdd5f292c77ae5feee8f3f101ded473

With this authorship:

@piotrturski @PascalSchumacher 

piotrturski 
 authored 
and PascalSchumacher 
 committed 
on Dec 1, 2015


Gary

[1] 
https://github.com/apache/commons-io/blob/3ad22fe3d689781a76a92908d0bbc119b2c68892/src/main/java/org/apache/commons/io/input/InfiniteCircularInputStream.java#L48-L49

Re: [all] Amazon Corretto

[Pascal Schumacher]

Isn't this basically the same as Adopt Open JDK:

https://adoptopenjdk.net

or am I missing something?

-Pascal

Am 14.11.2018 um 15:14 schrieb Rob Tompkins:

Curious to see what people’s thoughts are to this:

https://aws.amazon.com/corretto/

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




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

Re: [CONFIGURATION] 2.4 RC2 test failures with java 11 (Was: [VOTE] Release Apache Commons Configuration 2.4 based on RC2)

[Pascal Schumacher]

I would guess this is caused by a byte code manipulation library like 
ASM which does not support Java 11 yet.


Am 26.10.2018 um 16:28 schrieb Rob Tompkins:

Yes…those failures happen in 11, but not 10. Thoughts?


On Oct 26, 2018, at 9:59 AM, Gary Gregory  wrote:

Ping? Anybody see this as well?

Gary

On Thu, Oct 25, 2018 at 9:27 AM Gary Gregory  wrote:


 From src zip: ASC, SHA256, SHA512 OK.

Building OK with 'mvn -V clean package site' using

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T12:33:14-06:00)
Maven home: C:\Java\apache-maven-3.5.4\bin\..
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_191\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

But using Java 11:

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T12:33:14-06:00)
Maven home: C:\Java\apache-maven-3.5.4\bin\..
Java version: 11.0.1, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk-11.0.1
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

I get:

[INFO] Running
org.apache.commons.configuration2.reloading.TestFileHandlerReloadingDetector
[ERROR] Tests run: 11, Failures: 0, Errors: 5, Skipped: 0, Time elapsed:
0.008 s <<< FAILURE! - in
org.apache.commons.configuration2.reloading.TestFileHandlerReloadingDetector
[ERROR]
testRefreshIsReloadingRequiredTrue(org.apache.commons.configuration2.reloading.TestFileHandlerReloadingDetector)
Time elapsed: 0.002 s  <<< ERROR!
java.lang.IllegalArgumentException: Unsupported class file major version 55
at
org.apache.commons.configuration2.reloading.TestFileHandlerReloadingDetector.testRefreshIsReloadingRequiredTrue(TestFileHandlerReloadingDetector.java:131)

[ERROR]
testRefreshReloadingAndReset(org.apache.commons.configuration2.reloading.TestFileHandlerReloadingDetector)
Time elapsed: 0 s  <<< ERROR!
java.lang.IllegalArgumentException: Unsupported class file major version 55
at
org.apache.commons.configuration2.reloading.TestFileHandlerReloadingDetector.testRefreshIsReloadingRequiredTrue(TestFileHandlerReloadingDetector.java:131)

[ERROR]
testReloadingAndReset(org.apache.commons.configuration2.reloading.TestFileHandlerReloadingDetector)
Time elapsed: 0 s  <<< ERROR!
java.lang.IllegalArgumentException: Unsupported class file major version 55
at
org.apache.commons.configuration2.reloading.TestFileHandlerReloadingDetector.testRefreshIsReloadingRequiredTrue(TestFileHandlerReloadingDetector.java:131)

[ERROR]
testRefreshDelay(org.apache.commons.configuration2.reloading.TestFileHandlerReloadingDetector)
Time elapsed: 0 s  <<< ERROR!
java.lang.IllegalArgumentException: Unsupported class file major version 55
at
org.apache.commons.configuration2.reloading.TestFileHandlerReloadingDetector.testRefreshIsReloadingRequiredTrue(TestFileHandlerReloadingDetector.java:131)

[ERROR]
testIsReloadingRequiredTrue(org.apache.commons.configuration2.reloading.TestFileHandlerReloadingDetector)
Time elapsed: 0 s  <<< ERROR!
java.lang.IllegalArgumentException: Unsupported class file major version 55
at
org.apache.commons.configuration2.reloading.TestFileHandlerReloadingDetector.testRefreshIsReloadingRequiredTrue(TestFileHandlerReloadingDetector.java:131)

Any thoughts on that?

Gary

On Tue, Oct 23, 2018 at 8:10 PM Rob Tompkins  wrote:


We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Configuration 2.3 was released, so I would like to
release Apache Commons Configuration 2.4.

Apache Commons Configuration 2.4 RC2 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2
(svn revision 30260)

The Subversion tag for this RC is here:

http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_4_RC2/
(svn revision 1844715)

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1391/org/apache/commons/commons-configuration2/2.4/

These are the Maven artifacts and their hashes in Nexus:

#Nexus SHA-1s

commons-configuration2-2.4-sources.jar=2bcdd60dac93e16b53f613f37979b585cb5c23ec
commons-configuration2-2.4.pom=24b3e7ef8afc470ead058236dd71a73a0f029d9d

commons-configuration2-2.4-test-sources.jar=1f1fc7fad84049f55a6b9f28e9cacde46971bad6

commons-configuration2-2.4-tests.jar=a6c0ef84d06fb110681ee4ffc46f8d2d0436d203

commons-configuration2-2.4-javadoc.jar=e73305477e5d62ad0e140b58aa7e87dd0dbd1266
commons-configuration2-2.4.jar=208279841cb092e0f51f097c1f1649341e6333f3

#Release SHA-256s
#Tue Oct 23 21:49:00 EDT 2018

commons-configuration2-2.4-bin-tar.gz=25a59714dbeb379263d5b05d88a22ce0a6521cbd4b29e0d43630e8375cbb2776

commons-configuration2-2.4-bin-zip=cb9b1979ec07dbfb7ffc8b1a4e897210942ab85e8c91fcaba0a2de88fad274cd

Re: [VOTE] Release Apache Commons Text 1.6 based on RC1

[Pascal Schumacher]

+1

Am 13.10.2018 um 17:56 schrieb Gary Gregory:

*+1*

Thank you Rob for preparing this RC.

 From src zip: ASC, SHA256, and SHA512 OK.

Building 'mvn -V clean package site' OK using:

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T12:33:14-06:00)
Maven home: C:\Java\apache-maven-3.5.4\bin\..
*Java version: 11, vendor: Oracle Corporation*, runtime: C:\Program
Files\Java\jdk-11
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T12:33:14-06:00)
Maven home: C:\Java\apache-maven-3.5.4\bin\..
*Java version: 1.8.0_181, vendor: Oracle Corporation*, runtime: C:\Program
Files\Java\jdk1.8.0_181\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T12:33:14-06:00)
Maven home: C:\Java\apache-maven-3.5.4\bin\..
*Java version: 12-ea, vendor: Oracle Corporation*, runtime: C:\Program
Files\Java\jdk-12
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

All reports look OK but note that the build correctly on generates the
Jacoco report on Java 8 as it fails on later versions like Java 11 for
example.

Gary

On Fri, Oct 12, 2018 at 8:02 PM Rob Tompkins  wrote:


We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Text 1.5 was released, so I would like to release
Apache Commons Text 1.6.

Apache Commons Text 1.6 RC1 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/text/1.6-RC1 (svn
revision 30029)

The Git tag commons-text-1.6-RC1 commit for this RC is
7643b12421100d29fd2b78053e77bcb04a251b2e which you can browse here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=refs/tags/commons-text-1.6-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1388/org/apache/commons/commons-text/1.6/

These are the Maven artifacts and their hashes in Nexus:
#Release SHA1s For Nexus artifacts
commons-text-1.6-sources.jar=537f45636348da7c83861c537ec5ebb36933f5f4
commons-text-1.6.pom=f3942fd10a28871e0d2777c5597740edc00877d6
commons-text-1.6-tests.jar=74e92bbe2dde9fa26952fc26d63c9eb9d1625874
commons-text-1.6-javadoc.jar=72ecac738bee41dc39d7e987e93446a98f2d067e
commons-text-1.6.jar=ba72cf0c40cf701e972fe7720ae844629f4ecca2
commons-text-1.6-test-sources.jar=dcef8893a04e168c5f934e8fc4236312c690d6c7
#Release SHA-256s
#Fri Oct 12 19:42:59 MDT 2018

commons-text-1.6-javadoc-javadoc=2b5bb81936c95d53ee7aa5e3893c85271f0282472c1ba0e1e70c7af3eb653451

commons-text-1.6-src-zip=b9a155e6f2522749b6968fff8da52913dd0d59ed7b9d924381e26c706fe088d5

commons-text-1.6-bin-zip=102448b113144edd3a64168826abd33ea36f1890a1e6af17aeb126c0ca794fac

commons-text-1.6-sources-java-source=f1d31e721b929372da72616e7f493f1916a3268624a0a596a0c1f7abd2c7caf0

commons-text-1.6-test-sources-java-source=f5ea53c10db97e413cf27208fac60563b74e2cdeb6a1653ff27efa08776d20d9

commons-text-1.6-tests-test-jar=18c478c8d9af2fa8937a402b53ed239887837a682e6e915d6e837c190752b28a

commons-text-1.6-bin-tar.gz=5d6615fc89b9a8934da89e876069a44e475cf3db0fee91ab32da1c1f0e8908b0

commons-text-1.6-src-tar.gz=643e64ef7c7fd3a91875a1e33abc5648b057fe9729b466ddc6b7dbd7ec2b7c7a



I have tested this with ***'mvn clean install site'*** using:
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T12:33:14-06:00)
Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 11, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac"


Details of changes since 1.5 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/text/1.6-RC1/RELEASE-NOTES.txt

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

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

CLIRR Report (compared to 1.5):

https://dist.apache.org/repos/dist/dev/commons/text/1.6-RC1/site/clirr-report.html

JApiCmp Report (compared to 1.5):

https://dist.apache.org/repos/dist/dev/commons/text/1.6-RC1/site/japicmp.html

RAT Report:

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

KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 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,

Rob Tompkins,
Release Manager (using key 

Re: GitHub Pull Requests

[Pascal Schumacher]

Hi Zack,

there is no hard and fast rule when pull request get reviewed and/or 
commented on.


It happens whenever a committer feels motivated to do so (we are all 
volunteers).


I understand that waiting a long time for pull request reviews is 
demotivating.


Sorry,
Pascal

Am 11.10.2018 um 22:15 schrieb zmacom...@avadasoftware.com:

Hello,

I have submitted a Pull Request at 
https://github.com/apache/commons-lang/pull/358.  10 days ago, 
"coveralls" commented on the request and all checks passed. Otherwise, 
I have heard nothing regarding the request.


When do requests get reviewed and/or commented on?

Thanks,
Zack Macomber

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




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

Re: [VOTE] Release Apache Commons Text 1.5 based on RC3

[Pascal Schumacher]

+1

Am 01.10.2018 um 17:03 schrieb Gary Gregory:

+1

 From src zip: ASC, SHA256, SHA512 OK.
Build from src zip with 'mvn clean package site' OK using:

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T12:33:14-06:00)
Maven home: C:\Java\apache-maven-3.5.4
Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_181\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Reports OK.

Sanity manual check 'mvn clirr:check' OK.
Sanity manual check 'mvn apache-rat:check' OK.

Tag and src zip compare OK.

Gary

On Mon, Oct 1, 2018 at 7:03 AM Rob Tompkins  wrote:


We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Text 1.4 was released, so I would like to release
Apache Commons Text 1.5.

Apache Commons Text 1.5 RC3 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC3 (svn
revision 29819)

The Git tag commons-text-1.5-RC3 commit for this RC is
4736b16d0e644289f3106275ebb1315750234e40 which you can browse here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=refs/tags/commons-text-1.5-RC3

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1386/org/apache/commons/commons-text/1.5/

These are the Maven artifacts and their hashes in Nexus:

#Nexus SHA-1s
commons-text-1.5.pom=c2e89b076b2521ebc904a4880cf6338b59c2ac79
commons-text-1.5-sources.jar=3f34009d1d7bd216d7af5da542273f81950fdd7c
commons-text-1.5.jar=e9054ac321b9240440462532991c1d29d517c82d
commons-text-1.5-tests.jar=e289230025ea112af417e852c6ea483d2fc26d40
commons-text-1.5-test-sources.jar=53dcd066340b7ea678f14b4a8f9b8c9713581b46
commons-text-1.5-javadoc.jar=aecce693e827b974dfff526c84571d65cb8bfd35

#Release SHA-256s
#Mon Oct 01 08:52:13 EDT 2018

commons-text-1.5-src-tar.gz=e74197b63f2fdb82d3eb813f348b1fa736bcce084e580f9768aa127acbfa6194

commons-text-1.5-javadoc-javadoc=c7eb048768a67faa37ceccd4f049cf4d618c57941a6f46435e9928019feaa8a7

commons-text-1.5-src-zip=3a88a20050e4a4f8033ee35cc25e59db86de6c0c7597427df3615c986cc1cf80

commons-text-1.5-bin-tar.gz=a62724a89014d1ae2460d3699d99469391db4db2b39928398304deb49adc4b33

commons-text-1.5-tests-test-jar=34aecf32ca739bc8a74e80ea4185cbb83b61793443ccb7b1c3e23486dc1853e1

commons-text-1.5-bin-zip=447d99d56a3cbb366ac345ed9fe640f88f6258db0c198018d4b552c4f9bfe0a4

commons-text-1.5-test-sources-java-source=c905aff4cb65ea6b5ba15b9066b0b0760bfe12f7420fd5909970cee7369fc813

commons-text-1.5-sources-java-source=00c37e139210b2bf41a2bd32fdf58c3a74c85303a7dbfc54db5983a48d43bc44

I have tested this with 'mvn clean test package site' using:
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T14:33:14-04:00)
Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 10.0.2, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac"

Details of changes since 1.4 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC3/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC3/site/changes-report.html

Site:
 https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC3/site
 (note some *relative* links are broken and the 1.5 directories are not
yet created - these will be OK once the site is deployed.)

CLIRR Report (compared to 1.4):

https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC3/site/clirr-report.html

JApiCmp Report (compared to 1.4):

https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC3/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC3/site/rat-report.html

KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 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,

Rob Tompkins,
Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314)
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





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

Re: [VOTE] Release Apache Commons Text 1.5 based on RC1

[Pascal Schumacher]

+1

Am 29.09.2018 um 03:36 schrieb Gary Gregory:

Hi,

It looks like I did not spot what Spotbugs found :-(

https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC1/site/spotbugs.html


The only real worrisome one IMO is:
"org.apache.commons.text.lookup.PropertiesStringLookup.lookup(String)
may fail to close stream"

If we fix one, we might as well fix them all.

WDYT?

Gary

On Fri, Sep 28, 2018 at 12:37 PM Rob Tompkins  wrote:


We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Text 1.4 was released, so I would like to release
Apache Commons Text 1.5.

Apache Commons Text 1.5 RC1 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC1 (svn
revision 29768)

The Git tag commons-text-1.5-RC1 commit for this RC is
d3d93c4e68ce5d8c25aecbfff9d17017594bf3f2 which you can browse here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=refs/tags/commons-text-1.5-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1382/org/apache/commons/commons-text/1.5/

These are the Maven artifacts and their hashes in Nexus:

#Nexus SHA-1s
commons-text-1.5.pom
(SHA1: 82df3464f1d6b7b99eb6cc92069739a6234c9710)
commons-text-1.5-sources.jar
(SHA1: 3e39eac3b213fe33e2b60eb4322cb44f7d7a1680)
commons-text-1.5.jar
(SHA1: 9fdbd9e3d4507ef6640fb762f1e0e27c0fabbfe2)
commons-text-1.5-tests.jar
(SHA1: 142ea354f65e5db0ae291d2eec8a2100defd45af)
commons-text-1.5-test-sources.jar
(SHA1: e60a4ce76ff8f91ae034340c11fc2e01e332f644)
commons-text-1.5-javadoc.jar
(SHA1: c3d0e95dc0d2971ccc50fd9b92a54ff78d92338a)


#Release SHA-256s
#Fri Sep 28 14:18:44 EDT 2018

commons-text-1.5-tests-jar.asc=83bb485bddd78093e3989a03700c275b4ef1fd83beb8abffd8661bb5f87de3ef

commons-text-1.5-src-tar.gz=d73cf4c19b2348d342b74736daade40f7de29542ba8522110d997f40d6384085

commons-text-1.5-javadoc-javadoc=effed126a7686c33ae9a37da820a0e8f06bb540b35e0cda7e0ada1034d82c64a

commons-text-1.5-src-zip=c550dfa289c0f0a53a7b3683eea1181e9080cc5db930fd7f8b5f8969573a915d

commons-text-1.5-bin-tar.gz=6ad6fed2c51c8de75492d889d23876d5b7cfdad4db4cfda241e71d976830fd50

commons-text-1.5-tests-test-jar=b4f77797fd5bb41fecf518cb94cf5dd8b8e6a463ca6d0a9cb7807a46cd894466

commons-text-1.5-bin-zip=02a121a4d223c0f5cdf86b36dd362685faaa359ea2fc114437a199942d2f8f82

commons-text-1.5-test-sources-java-source=13f22c7fdd74c5f12fd4d2855367d446f159030d91cf182d1597ffbf8c1cbd16

commons-text-1.5-sources-java-source=6540b6ea96f39fe5df2dd4aad3f4a7c0eea239222073742edc8693483d300438

#Release SHA-512s
#Fri Sep 28 14:18:44 EDT 2018

commons-text-1.5-src-tar.gz=41e0aa28dd89579f6b3731069082dac3e69b8d946fba841c344851d112ed944f974c37f5a355259afe1fada0faf35f18fed01e74150ecda19fc0764f1ae4f48c

commons-text-1.5-javadoc-javadoc=abbcf3a3b87af36808603eea8cb7db96d53cdedbfb924bc41c88776774db494cdf09fa9e112118afef825114eda79a4faa1eed554273777a9113b54c823ce73c

commons-text-1.5-src-zip=b9014bc80ca991cc119e57365aee1feffc697233abf72fbdc2d71ed42ab28721374feef827720cde97219e935cdb5b07c3a2bf9c78c8ae498674022bbac829f6

commons-text-1.5-bin-tar.gz=068e000563e522a1f4b96f6b1769284edcdf360f1e706317e2f09f9c7b3fc4eeb2c19274db64cf2312160ad3a94f4f63d4676f09f16380c592b7fe0eace3cad6

commons-text-1.5-tests-test-jar=2008550b1f5c3ca83d9bed8fa8a668ad8e5830de0325df95626dfe1a716c81c4a51983673b49fc37216e38e22e0b799a6fae0b8884abeb6bcec066ba9a1a

commons-text-1.5-bin-zip=6d3e249627b770bfa538f656d7fd91ed4582c0065fe8c41fa2cce57a1693dd4432d789ed1753e38bf839f4ac235e3f0b8b97d6974f565ea679e1289bf00929af

commons-text-1.5-test-sources-java-source=9b194d7c5c8ab3bc9704a5c79e48bcaac350a33eab4cbdad486d1cd8acea3b1f6749940f797222eff7c8039a3855f3393d5ff3c7b3114a1d7af3fc48408f9a98

commons-text-1.5-sources-java-source=c9c897abbdfabf418444806e69f0eb0a955fad81194efe13192985533741739f38407973d7a6c3977198f74a70e6907a524f4b3de634cad0991a4bb0757f


I have tested this with ***'mvn clean install site'*** using:
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T14:33:14-04:00)
Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 10.0.2, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac"


Details of changes since 1.4 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC1/RELEASE-NOTES.txt

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

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

CLIRR Report (compared to 1.4):

https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC1/site/clirr-report.html

JApiCmp Report (compared to 1.4):

Re: [LANG] Request for Comments for LANG-1417

[Pascal Schumacher]

Hi Benedikt,

not sure if anything is gained this change.

It is already possible use lambda expressions or method references 
instead of ThreadPredicate/ThreadGroupPredicate.


Users will have to change their code to avoid deprecation warnings.

I would prefer to just annotate ThreadPredicate and ThreadGroupPredicate 
with @FunctionalInterface and be done.


Regards,
Pascal

Am 28.08.2018 um 11:32 schrieb Benedikt Ritter:

Hi,

I've implemented a proposal to get rid of ThreadPredicate and
ThreadGroupPredicate in ThreadUtils [1]. I have two questions about this
issue:

1) It does not seem possible to let our custom pre Java 8 predicates extend
java.util.function.Predicate. I've explained why I think this is not
possible in LANG-1417 [2]. I'd like to here comments about that. Am I
missing something?
2) Should be put the new java.util.function.Predicate based API inside
ThreadUtils or should we deprecate ThreadUtils all together und create a
new version of the class (ThreadUtils2 / ThreadUtilsJava8 /
org.apache.commons.thread.ThreadUtils) that only operates on Predicates?

Regards,
Benedikt

[1] https://github.com/apache/commons-lang/349
[2] https://issues.apache.org/jira/browse/LANG-1417




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

Re: [ALL] Make checkstyle:check part of default maven goal?

[Pascal Schumacher]

At least RAT and clirr/japicmp should be part of default goal.

I'm personally prefer checkstyle and findbugs/spotbugs (although I 
prefer error-prone nowadays) to be part of the default goal.


On Java 8+ it is also helpful to make javadoc part of the default goal.

I think it is very convenient to be able to execute everything with 
"mvn" before committing and have the build fail if there are any 
violations. It is also helpful for pull request, because travis can run 
the default goal too.


By the way: lang and text already have all these as default goal and io 
is just missing findbugs.


Cheers,
Pascal

Am 20.08.2018 um 21:06 schrieb Gary Gregory:

The RAT check should be turned on by default IMO.

Gary

On Mon, Aug 20, 2018 at 12:45 AM Benedikt Ritter  wrote:


Hi,

one thing I always have to do when preparing a release is to fix all the
checkstyle and findbugs errors. This step could be eliminated if we added
checkstyle:check and findbugs:check to the maven default goal. This way it
would be executed on CI builds and we would see failing checkstyle/findbugs
right away.

WDYT?
Benedikt




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

[text] Recently added Checkstyle Violations

[Pascal Schumacher]

Hi,

the build of text fails, because of checkstyle violations:

[INFO] There are 8 errors reported by Checkstyle 8.12 with 
/home/travis/build/apache/commons-text/checkstyle.xml ruleset.
[ERROR] 
src/main/java/org/apache/commons/text/lookup/AbstractStringLookup.java:[27,5] 
(javadoc) JavadocVariable: Missing a Javadoc comment.
[ERROR] 
src/main/java/org/apache/commons/text/lookup/AbstractStringLookup.java:[28,5] 
(javadoc) JavadocVariable: Missing a Javadoc comment.
[ERROR] 
src/main/java/org/apache/commons/text/lookup/ScriptStringLookup.java:[81] 
(sizes) LineLength: Line is longer than 120 characters (found 121).
[ERROR] 
src/main/java/org/apache/commons/text/lookup/UrlStringLookup.java:[21,8] 
(imports) UnusedImports: Unused import - java.io.InputStream.
[ERROR] 
src/main/java/org/apache/commons/text/lookup/UrlStringLookup.java:[25,8] 
(imports) UnusedImports: Unused import - java.nio.file.Files.
[ERROR] 
src/main/java/org/apache/commons/text/lookup/UrlStringLookup.java:[78,44] 
(coding) MagicNumber: '8192' is a magic number.
[ERROR] target/test-classes/document.properties:[0] (misc) 
NewlineAtEndOfFile: File does not end with a newline.
[ERROR] src/test/resources/document.properties:[0] (misc) 
NewlineAtEndOfFile: File does not end with a newline.


It would be nice, if these were fixed by whoever added them.

Thanks,
Pascal

Re: [LANG] Minimum required Java version for 3.9

[Pascal Schumacher]

+1

Am 20. August 2018 19:09:27 MESZ schrieb Benedikt Ritter :
>Hi,
>
>any objections against raising the minimum required Java version for
>lang
>3.9 to Java 1.8?
>
>Regards,
>Benedikt

Re: I'm alive!

[Pascal Schumacher]

Welcome back! :-)

Am 16.08.2018 um 16:59 schrieb Benedikt Ritter:

Hi all,

I have been pretty quite over the past 12 month. There are a lot of reasons
for this. The most important reasons are:
- I've been Lead Developer in a very challenging project which included a
lot of traveling between my home and Hamburg (which is about 250km from
here).
- I got married, and there was a lot of planning to do for the wedding.

But now I'm back and I want to start working on commons again. Looking
forward to collaborate with you again!

Regards,
Benedikt




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

Re: [lang] preparing for 3.8

[Pascal Schumacher]

Am 14.08.2018 um 14:15 schrieb Gary Gregory:

Not a blocker IMO. We can release 3.8 and work on this for 3.9.


+1

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

Re: [lang] preparing for 3.8

[Pascal Schumacher]

Yes, a new lang release would be great. :-)

Thanks,
Pascal

Am 14.08.2018 um 03:31 schrieb Gary Gregory:

Go for it! :-)

Gary

On Mon, Aug 13, 2018, 18:36 Rob Tompkins  wrote:


Hello all,

I’m planning on working on 3.8 for lang later this week. Does anyone want
to get any specific jira's in? I think that I can quickly button up
LANG-1408 (selfishly want to get that in).

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





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

Re: [imaging] Move from Java7 to Java8

[Pascal Schumacher]

Hi Bruno,

imho it would be preferable to release 1.0 using Java 7. That would 
allow everybody using snapshots to replace them with a release. E.g. 
https://github.com/LibrePDF/OpenPDF is using a snapshot but is still on 
Java 7.


After the release we can update to Java 8 for 1.1.

Cheers,
Pascal

Am 12.08.2018 um 00:46 schrieb Bruno P. Kinoshita:

Hi all,

Since Sanselan became Commons Imaging, some work has been done, but there was 
never an official release.

The project is using Java7, and I would like to update it to use Java 8. Any 
objections?

My plan is to just update to Java8 now and prepare the 1.0 release vote. Then 
slowly add Java 8 improvements over the 1.x releases, and perhaps even add 
support to Java 9 before a 2.x if possible.


Thanks
Bruno

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




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

Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

[Pascal Schumacher]

I think we should deprecate without replacement.

There are already plenty Apache 2.0 licensed libraries offering circuit 
breaker implementations:


https://github.com/Netflix/Hystrix
https://github.com/jhalterman/failsafe
https://github.com/resilience4j/resilience4j

Cheers,
Pascal

Am 16.07.2018 um 23:30 schrieb Bruno P. Kinoshita:

What about introducing our own state listener interface? The original
interface from the beans package was used just for convenience because
it already existed. But it would of course be possible to have a simple
functional interface to notify listeners about state changes.

Hmmm, that's an option as well.
Looks like they had the beans interface which we used, then later we had the 
java.util.Observable for a while, and now they are suggesting users to move to 
the beans interface, as one of the alternatives.
As some Java 9 users possibly wouldn't want to import the java.beans module, 
perhaps having this new interface could be an interesting alternative.
I believe we would have to
[ ] decide whether to introduce an interface similar to PropertyListener, or to 
Observable[ ] if the backward compatibility changed, we must deprecate the 
existing classes
[ ] release a new version of lang with this new interface and the updated 
circuit breakers[ ] and either delete the deprecated classes or leave it until 
for some more releases
I wonder what others think about this option?

Cheers
Bruno


   From: Oliver Heger 
  To: dev@commons.apache.org
  Sent: Tuesday, 17 July 2018 4:13 AM
  Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop 
(Was: Re: [LANG] Thoughts about Lang 4.0)




Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:

Saw some recent activity around lang 3.8, and remembered about this issue, and 
then looked for this thread.

Gilles' point is really good! Here's the Java 9 docs with the deprecation 
warning, copied below as well 
https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html


"This class and the Observer interface have been deprecated. The event model 
supported by Observer and Observable is quite limited, the order of notifications 
delivered by Observable is unspecified, and state changes are not in one-for-one 
correspondence with notifications. For a richer event model, consider using the 
java.beans package.  For reliable and ordered messaging among threads, consider using one 
of the concurrent data structures in the java.util.concurrent package. For reactive 
streams style programming, see the Flow API."



So I guess the best we can do right now is add the @deprecated annotations, 
with an explanation in the javadocs. And also add a note about it in the 
release notes.

Does that sound like a good plan? Adding a link to this thread in the pull 
request as well.


What about introducing our own state listener interface? The original
interface from the beans package was used just for convenience because
it already existed. But it would of course be possible to have a simple
functional interface to notify listeners about state changes.

Oliver


Cheers
Bruno





From: Stephen Colebourne 
To: Commons Developers List 
Sent: Monday, 11 June 2018 9:26 AM
Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop 
(Was: Re: [LANG] Thoughts about Lang 4.0)



Good spot. I think that means [lang] would have to have its own copy
of the JDK interfaces. or just deprecate the functionality without
replacement.
Stephen

On 10 June 2018 at 22:11, Gilles  wrote:

Hello.

On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:

Hi Bruno,

Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:

Hi all,

There is a patch [1] for LANG-1339 [2] that I would like to merge. The
discussion around this issue can be found in the rest of this e-mail thread.

The patch basically deprecates the existing classes that depend on
java.desktop, and provide alternative implementations. The previous classes
used java.desktop classes for the PropertyChangeListener. And the
alternative ones instead use Java 7's java.util.Observer.


Is it a good idea to use deprecated classes[1] in new code?

Regards,
Gilles

[1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html




This will make it easier to provide [lang] as java 9, without requiring
users to include a dependency to java.desktop.
Planning to merge it during the next week if there are no objections
here.

Thanks,
Bruno


agreed. This seems to be the best what we can do.

Oliver



[1] https://github.com/apache/commons-lang/pull/275

[2] https://issues.apache.org/jira/browse/LANG-1339



From: Benedikt Ritter

To: Commons Developers List 
Sent: Monday, 5 June 2017 10:49 PM
Subject: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)





Am 25.05.2017 um 18:23 schrieb Oliver Heger
:



Am 24.05.2017 um 13:55 schrieb Stephen 

Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

[Pascal Schumacher]

Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:

Saw some recent activity around lang 3.8, and remembered about this issue, and 
then looked for this thread.

Gilles' point is really good! Here's the Java 9 docs with the deprecation 
warning, copied below as well 
https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html


"This class and the Observer interface have been deprecated. The event model 
supported by Observer and Observable is quite limited, the order of notifications 
delivered by Observable is unspecified, and state changes are not in one-for-one 
correspondence with notifications. For a richer event model, consider using the 
java.beans package.  For reliable and ordered messaging among threads, consider using one 
of the concurrent data structures in the java.util.concurrent package. For reactive 
streams style programming, see the Flow API."



So I guess the best we can do right now is add the @deprecated annotations, 
with an explanation in the javadocs. And also add a note about it in the 
release notes.

Does that sound like a good plan?


Sounds good to me!

Cheers,
Pascal

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

Re: [Lang] Rounding Duration

[Pascal Schumacher]

Am 15.07.2018 um 22:09 schrieb Gary Gregory:

Let's cut a Lang release and then update to Java 8.


+1

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

Re: [Lang] Rounding Duration

[Pascal Schumacher]

Hi Aleksander,

guess you are referring to java.time.Duration?

This class was added in Java 8 and commons-lang currently only requires 
Java 7. Therefore we can not add this at the moment.


Sorry,
Pascal

Am 14.07.2018 um 21:26 schrieb Aleksander Ściborek:

Hello everyone
During implamanting a feauture in Java I noticed that there is no methods
to round duration for instance:
between 10:00 and 12:31 there is 2h 31 min. I want to write some methods to
reduce boilerplate code to calculate  time in given unit between temporals
and round this time - e.g. for 2 h 31 minutes it should return 3 hours
Aleksander




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

Re: Porting URIBuilder call sites

[Pascal Schumacher]

I guess this was send to the wrong mailing list?

Am 12.07.2018 um 17:22 schrieb Gary Gregory:

Hi All,

I just had to port this 'nice' fluent code:

 final String uri = new URIBuilder()
 .setScheme(scheme)
 .setHost("localhost")
 .setUserInfo(userInfo)
 .setPort(proxyPort)
 .setPath(path)
 .setCustomQuery(queryParameterString)
 .build()
 .toString();

to:

 final URIBuilder builder = new URIBuilder()
 .setScheme(scheme)
 .setHost("localhost")
 .setPort(proxyPort)
 .setPath(path)
 .setCustomQuery(queryParameterString);
 if (StringUtils.isNotBlank(userInfo)) {
 builder.setUserInfo(userInfo);
 }
 final String uri = builder.build().toString();

To avoid an IllegalArgumentException when userInfo is "":

java.lang.IllegalArgumentException: User info may not be empty
at org.apache.hc.core5.util.Args.containsNoBlanks(Args.java:84)
at org.apache.hc.core5.net.URIAuthority.(URIAuthority.java:73)
at
org.apache.hc.core5.http.message.BasicHttpRequest.setUri(BasicHttpRequest.java:172)
at
org.apache.hc.core5.http.message.BasicHttpRequest.(BasicHttpRequest.java:102)
at
org.apache.hc.core5.http.message.BasicClassicHttpRequest.(BasicClassicHttpRequest.java:77)
at
org.apache.hc.client5.http.classic.methods.HttpUriRequestBase.(HttpUriRequestBase.java:48)
at
org.apache.hc.client5.http.classic.methods.RequestBuilder.build(RequestBuilder.java:482)
at
com.rs.seagull.httpmonitor.ClientTests.testHttpMethod(ClientTests.java:106)
...

I would be nice to still offer this fluent style when userInfo is null (and
even "")

Thoughts?

Gary




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

Re: [dbcp] Next

[Pascal Schumacher]

+1

Am 21.06.2018 um 20:33 schrieb Matt Sicker:

I'd stick with 2.x since it's still backwards compatible. Upgrading the
base Java version is not a semantic change IMO, but it shouldn't be done in
a patch release.

On 19 June 2018 at 16:48, Gary Gregory  wrote:


To be clear:

DBCP 2.4.0 -  Java 7 - JDBC 4.1 (just released)
DBCP 2.5.0 or 3.0.0  -  Java 8 - JDBC 4.2 (in git master)
DBCP 2.6.0 or 4.0.0  -  Java 9 - JDBC 4.3 (to do)

Thoughts?

Gary



On Tue, Jun 19, 2018 at 2:28 PM Gary Gregory 
wrote:


I have no API breaking changes for 3.0, so I do not see a need for a

major

version change. Feedback welcome. I am more interested in getting the

next

version out to pick up the new methods from JDBC 4.2 on Java 8.

Gary

On Tue, Jun 19, 2018, 13:49 Matt Sicker  wrote:


Bumping to 3.0 could allow for adopting lessons from other connection

pool

libraries in API incompatible ways. I have no specific examples, but
HikariCP is a general one.

On 19 June 2018 at 14:27, Jochen Wiedmann 
wrote:


On Sun, Jun 17, 2018 at 2:42 PM Gary Gregory 
wrote:


3.0.0 somewhat implies API breakage which has not happened yet so

2.5.0

is

better for now IMO...

+1 for going to 3.0.0 anyways. This would perhaps fix the problem for
Tomcat, assuming that we keep a maintenance branch for 2.x.

Jochen

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




--
Matt Sicker 







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

Re: [parent] release?

[Pascal Schumacher]

+1

Am 20.06.2018 um 19:58 schrieb Gary Gregory:

Are we ready?

Gary




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

Re: [parent] cobertura dead, replace with jacoco?

[Pascal Schumacher]

+1

Am 20.06.2018 um 22:37 schrieb Gary Gregory:

It seems cobertura has not been updated since 2015 (
https://github.com/cobertura/cobertura/releases) and does not work on Java

9:

[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 05:24 min
[INFO] Finished at: 2018-06-20T14:28:47-06:00
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
project commons-pool2: failed to get report for
org.codehaus.mojo:cobertura-maven-plugin: Plugin
org.codehaus.mojo:cobertura-maven-plugin:2.7 or one of its dependencies
could not be resolved: Could not find artifact com.sun:tools:jar:0 at
specified path C:\Program Files\Java\jdk-9.0.4/../lib/tools.jar -> [Help 1]
[ERROR]

I say we remove it from commons-parent and use Jacoco from now on.

Thoughts?

Gary




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

Re: [release-plugin][build-plugin] Java 8

[Pascal Schumacher]

+1

Am 13.06.2018 um 23:07 schrieb Gary Gregory:

I propose we make our release-plugin require Java 8. Newer dependencies
like the latest Checkstyle require Java 8.

Gary




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

Re: [VOTE] Release Apache Commons Text 1.4 based on RC1

[Pascal Schumacher]

+1

Thank you very much for being the release manager!

Cheers,
Pascal

Am 09.06.2018 um 19:49 schrieb Gary Gregory:

We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Text 1.3 was released, so I would like to release
Apache Commons Text 1.4.

Apache Commons Text 1.4 RC1 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/text (svn revision 27356)

The Git tag commons-text-1.4-RC1 commit for this RC is
d9229655fdb335a9730bef6df789a46faa764b8a which you can browse here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=refs/tags/commons-text-1.4-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1330/org/apache/commons/commons-text/1.4/

These are the Maven artifacts and their hashes in Nexus:

#Release SHA-1s
#Sat Jun 09 11:15:59 MDT 2018
commons-text-1.4-java-source=47636f3b9ae54bc9618c2e3b1382f1de6297f326
commons-text-1.4-zip.asc=1158f083a0008d92da56cda0065c4cde6c46cb63
commons-text-1.4-javadoc=af2c89fd3df3f00a2dee80df84f8f2d961aa08e7
commons-text-1.4-zip=ca1cc6fbb4e46b44f8bb09b70c9e3a2ae3c5fce8
commons-text-1.4-tar.gz=0dcee421c4e03d6bc098a61a5cdcc90656856611
commons-text-1.4-test-jar=7dfd1a711b16b9379de9ddd9d5c9f9158ca2a38f
commons-text-1.4-jar.asc=24d2e7b8fadd041a3f661798caba035945e15df1
commons-text-1.4-pom.asc=4c97288cab505b297445409bcf79612606b7108b
commons-text-1.4-tar.gz.asc=efe2847068de99a566265c5ff827b127a2159adc

#Release SHA-256s
#Sat Jun 09 11:15:59 MDT 2018
commons-text-1.4-java-source=cfaede7310cb5f669c1c9ad2c0453f65a7f0dc704a4531f634944ecddc03c667
commons-text-1.4-zip.asc=f1f7d3d88f26656c5578d52a3a55e72f07f1ae19250af642336539bd7009
commons-text-1.4-javadoc=765d8236908e1aa7ee9dbbf165fdd993709ffb7d23991ca6be5f8a750b77a381
commons-text-1.4-zip=e4a6c992153faae4f7faff689b899073000364e376736b9746a5d0acb9d8b980
commons-text-1.4-tar.gz=1cb8536c375c3cff66757fd40c2bf878998254ba0a247866a6536bd48ba2e88a
commons-text-1.4-test-jar=078049288745a90d113b2a055471fec30d0c971c79571a9ff1414c9aeb1d70e1
commons-text-1.4-jar.asc=4d044e0f756bcb3487e3a55a58a430363a7df3127c5c68bcd97ef2ccb6b84028
commons-text-1.4-pom.asc=183a60ceeef006955198654556b044ef5baaf1c2f85404ae7c935dd0ddac4bf6
commons-text-1.4-tar.gz.asc=e21ff58d46797e3a9f014f6f37976d9f3beaab08385f549fee2a02b5e41bc574

(no need for .asc hashes!)

I have tested this with 'mvn clean install site' using:

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T12:49:05-07:00)
Maven home: C:\Java\apache-maven-3.5.3\bin\..
Java version: 1.8.0_172, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_172\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Details of changes since 1.3 are in the release notes:
 https://dist.apache.org/repos/dist/dev/commons/text/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/text/site/changes-report.html

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

CLIRR Report (compared to 1.3):

https://dist.apache.org/repos/dist/dev/commons/text/site/clirr-report.html

JApiCmp Report (compared to 1.3):
 https://dist.apache.org/repos/dist/dev/commons/text/site/japicmp.html

RAT Report:
 https://dist.apache.org/repos/dist/dev/commons/text/site/rat-report.html

KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 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 2DB4F1EF0FA761ECC4EA935C86FDC7E2A11262CB)




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

[all] - git: prevent unnecessary merge commits?

[Pascal Schumacher]

Hello everybody,

in my opinion it is a good practice to always use the "--rebase" option 
when using "git pull". This keeps the history free of unnecessary merge 
commits like "Merge branch 'master' of 
https://git-wip-us.apache.org/repo...;.


You can also tell git to automatically rebase when pulling:

git config --global pull.rebase true

What do you think?

Cheers,

Pascal


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

Re: [VOTE] Release Compress 1.17 based on RC1

[Pascal Schumacher]

I guess the build fails on java 11 because jacoco does not support java 
11 yet, see: https://github.com/jacoco/jacoco/issues/663


Cheers,
Pascal

Am 01.06.2018 um 17:19 schrieb Gary Gregory:

+1

 From src zip file: ASC, SHA-1, SHA-256 OK.

mvn apache-rat:check OK
mvn japicmp:cmp OK

mvn clean site OK

Generated site RAT report OK.
NO JApiCmp report generated for me but present on
https://stefan.samaflost.de/staging/commons-compress-1.17/
Other reports OK.

Typos already report in release notes.

Tested 'mvn clean test' OK with (mvn -version):

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T12:49:05-07:00)
Maven home: C:\Java\apache-maven-3.5.3\bin\..
Java version: *1.7.0_80*, vendor: *Oracle *Corporation
Java home: C:\Program Files\Java\jdk1.7.0_80\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T12:49:05-07:00)
Maven home: C:\Java\apache-maven-3.5.3\bin\..
Java version: *1.8.0_172*, vendor: *Oracle *Corporation
Java home: C:\Program Files\Java\jdk1.8.0_172\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T12:49:05-07:00)
Maven home: C:\Java\apache-maven-3.5.3\bin\..
Java version: *1.8.0*, vendor: *IBM* Corporation
Java home: C:\eclipse\IBM-6.4.5\ibm_sdk80\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "x86", family: "windows"

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T12:49:05-07:00)
Maven home: C:\Java\apache-maven-3.5.3\bin\..
Java version: *9.0.4*, vendor: *Oracle *Corporation
Java home: C:\Program Files\Java\jdk-9.0.4
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T12:49:05-07:00)
Maven home: C:\Java\apache-maven-3.5.3\bin\..
Java version: *10.0.1*, vendor: *Oracle *Corporation
Java home: C:\Program Files\Java\jdk-10.0.1
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

FAIL:

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T12:49:05-07:00)
Maven home: C:\Java\apache-maven-3.5.3\bin\..
Java version: *11-ea*, vendor: *Oracle* Corporation
Java home: C:\Program Files\Java\jdk-11
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

[INFO] ---
[INFO]  T E S T S
[INFO] ---
[WARNING] Corrupted STDOUT by directly writing to native stream in forked
JVM 1. See FAQ web page and the dump file
C:\temp\rc\commons-compress-1.17-src\target\surefire-reports\2018-06-01T09-16-26_459-jvmRun1.dumpstream
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 29.645 s
[INFO] Finished at: 2018-06-01T09:16:27-06:00
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.21.0:test (default-test)
on project commons-compress: There are test failures.
[ERROR]
[ERROR] Please refer to
C:\temp\rc\commons-compress-1.17-src\target\surefire-reports for the
individual test results.
[ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump,
[date].dumpstream and [date]-jvmRun[N].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM crash
or System.exit called?
[ERROR] Command was cmd.exe /X /C ""C:\Program Files\Java\jdk-11\bin\java"
-javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.1\\org.jacoco.agent-0.8.1-runtime.jar=destfile=C:\\temp\\rc\\commons-compress-1.17-src\\target\\jacoco.exec
-jar
C:\Users\ggregory\AppData\Local\Temp\surefire17035750934386353788\surefirebooter16013684410808460129.jar
C:\Users\ggregory\AppData\Local\Temp\surefire17035750934386353788
2018-06-01T09-16-26_459-jvmRun1 surefire785711158982866484tmp
surefire_03368209078764932780tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The
forked VM terminated without properly saying goodbye. VM crash or
System.exit called?
[ERROR] Command was cmd.exe /X /C ""C:\Program Files\Java\jdk-11\bin\java"

Re: [io] Black Duck apparently sees vulnerability in 2.5

[Pascal Schumacher]

Am 16.05.2018 um 08:24 schrieb Stefan Bodewig:

Also, would there be any reason to not cut a new release from master? I
mean is there any work in progress that needs to be finished?


I think a new release from master can be done any time.

-Pascal

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

Re: [DBCP] Drop Ant build?

[Pascal Schumacher]

+1 for droping it

Am 12.05.2018 um 20:36 schrieb Gary Gregory:

Commons DBCP still has an Ant build. Should we drop it?




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

Re: [BBUTILS] Update from Java 6 to 7

[Pascal Schumacher]

+1

Am 04.05.2018 um 18:19 schrieb Gary Gregory:

Hi All:

DBUtils contains the kind of code that would benefit from bullet proofing
using try-with-resources statementds.

To this end I propose we update from Java 6 to 7.

Gary




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

Re: [VOTE] Migrate existing Git repos to GitBox

[Pascal Schumacher]

+1

Am 22.04.2018 um 19:07 schrieb Matt Sicker:

This is a vote to migrate existing Git repositories from the old git-wip-us
infrastructure to the new gitbox infrastructure. New Apache projects are
not allowed to use git-wip-us and are instead directed to use gitbox. As
such, it makes sense for us to stay consistent with other projects.

The advantages to migrating to gitbox besides infra is much better GitHub
integration. The gist of how GitBox works is that git repos are mirrored
two-way between apache and github. The old git-wip-us github integration is
read-only which makes merging pull requests a chore and also makes the
github project pages a bit confusing as they aren't traditional github
projects as it is.

This vote only applies to existing git repositories at Commons. Existing
svn repositories will be covered in a different vote later on.

If you have a preference for Jira or GH Issues or something, please feel
free to add that to your vote. All existing projects are already in Jira as
it is.

References:
https://issues.apache.org/jira/browse/INFRA-16413
https://gitbox.apache.org/




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

Re: [VOTE] Migrate Commons Weaver to Git

[Pascal Schumacher]

+1

Am 19.04.2018 um 17:46 schrieb Matt Benson:

Hello,
After having received some support from a "feeler" email, I would like to
propose the formal vote to migrate this Commons component to Git for
version control. This vote will be open for at least 72 hours, or until
April 22, 2018 @ 16:00 UTC.

Thanks,
Matt




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

[text] Move to Java 8?

[Pascal Schumacher]

Hello,

what about moving text to Java 8, now that version 1.3 has been released?

Cheers,

Pascal


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

Re: [VOTE] Release Commons Text 1.3 based on RC1

[Pascal Schumacher]

+1

Am 16.03.2018 um 16:35 schrieb Rob Tompkins:

Hello all,

This is a [VOTE] for releasing Apache Commons Text 1.3 (from RC1).

Tag name:
commons-text-1.3-RC1 (signature can be checked from git using 'git tag
-v')

Tag URL:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=6e7a377e76bc7e34c286b5c5ee0433f00dc0d358

Commit ID the tag points at:
 4ac48357180c9222f032dd8b055d90e1192e4a47

Site Zip:
https://dist.apache.org/repos/dist/dev/commons/text/site.zip

Distribution files (committed at revision 25771):
https://dist.apache.org/repos/dist/dev/commons/text/

Distribution files hashes (SHA1):
commons-text-1.3-bin.tar.gz
(SHA: 992637a7dcd53bdfc7831f3dfba171b998119e10)
commons-text-1.3-bin.zip
(SHA1: 6f4c8785d57f6af21fe08218e7d82ce5404c291c)
commons-text-1.3-src.tar.gz
(SHA1: 987bd384cb11bb5f52ddf5c866058faa6a00a298)
commons-text-1.3-src.zip
(SHA1: f234bbb3d0816800d4f7b997b65edbbc3c66c87c)

These are the Maven artifacts and their hashes:
commons-text-1.3-javadoc.jar
(SHA1: 8e170d7068f08823c0ad208214a48506f2950cbc)
commons-text-1.3-sources.jar
(SHA1: 9c51853f855aca4ea31785f30385e980a58eaf4b)
commons-text-1.3-test-sources.jar
(SHA1: d8f817cae41c3664ed89933e137f007a8e0f2c7b)
commons-text-1.3-tests.jar
(SHA1: 97d5a4ea56febf105f85cd6783a9dd8492d880c2)
commons-text-1.3.jar
(SHA1: 9abf61708a66ab5e55f6169a200dbfc584b546d9)
commons-text-1.3.pom
(SHA1: 319d278bae93adc3f5b5e8408a90fd2d98ce75f7)

KEYS file to check signatures:
http://www.apache.org/dist/commons/KEYS

Maven artifacts:
https://repository.apache.org/content/repositories/orgapachecommons-1319

Please select one of the following options[1]:
   [ ] +1 Release it.
   [ ] +0 Go ahead; I don't care.
   [ ] -0 There are a few minor glitches: ...
   [ ] -1 No, do not release it because ...

This vote will be open at least 72 hours, i.e. until
2018-03-19T16:00:00Z
(this is UTC time).


Cheers,
-Rob

[1] http://apache.org/foundation/voting.html
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




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

Re: [email] Update from Java 6 to 7

[Pascal Schumacher]

+1, otherwise we would have to revert 
https://github.com/apache/commons-email/commit/2239326be5c2791a23eea07eaed3d81f2e7000cf


Am 02.03.2018 um 17:45 schrieb Gary Gregory:

I propose we update Commons Email from Java 6 to Java 7.

Gary

Re: Commit => Update Jira Issue

[Pascal Schumacher]

Hi Jochen,

you did not miss anything. Commons does not have any synchronization 
between commit messages and jira issues (or at least the projects I am 
aware of).


-Pascal

Am 21.02.2018 um 10:58 schrieb Jochen Wiedmann:

Hi,

I notice that my commit in [1] did not update the Jira issue in [2],
although I used the prefix "PR: IO-567"

Did I miss something?

Thanks,

Jochen

1: 
https://git-wip-us.apache.org/repos/asf?p=commons-io.git;a=commit;h=748eef8b96068cadc45894967f58f015860afb1b
2: https://issues.apache.org/jira/browse/IO-567

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




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

Re: [text] LocalHostStringLookupTest: correct order of assertEquals arguments

[Pascal Schumacher]

You are welcome!

-Pascal

Am 14.02.2018 um 21:31 schrieb Gary Gregory:

Good catch Pascal, thank you!

Gary

On Wed, Feb 14, 2018 at 12:59 PM, <pascalschumac...@apache.org> wrote:


Repository: commons-text
Updated Branches:
   refs/heads/master fb5d8c93a -> 6e9107dc8


LocalHostStringLookupTest: correct order of assertEquals arguments


Project: http://git-wip-us.apache.org/repos/asf/commons-text/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-text/commit/
6e9107dc
Tree: http://git-wip-us.apache.org/repos/asf/commons-text/tree/6e9107dc
Diff: http://git-wip-us.apache.org/repos/asf/commons-text/diff/6e9107dc

Branch: refs/heads/master
Commit: 6e9107dc826cee43629af6a3857c98c90da18eba
Parents: fb5d8c9
Author: Pascal Schumacher <pascalschumac...@gmx.net>
Authored: Wed Feb 14 20:58:41 2018 +0100
Committer: Pascal Schumacher <pascalschumac...@gmx.net>
Committed: Wed Feb 14 20:58:41 2018 +0100

--
  .../commons/text/lookup/LocalHostStringLookupTest.java   | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/commons-text/blob/
6e9107dc/src/test/java/org/apache/commons/text/lookup/
LocalHostStringLookupTest.java
--
diff --git 
a/src/test/java/org/apache/commons/text/lookup/LocalHostStringLookupTest.java
b/src/test/java/org/apache/commons/text/lookup/
LocalHostStringLookupTest.java
index ffcaf1c..c00a7dc 100644
--- a/src/test/java/org/apache/commons/text/lookup/
LocalHostStringLookupTest.java
+++ b/src/test/java/org/apache/commons/text/lookup/
LocalHostStringLookupTest.java
@@ -27,19 +27,20 @@ public class LocalHostStringLookupTest {

  @Test
  public void testAddress() throws UnknownHostException {
-Assert.assertEquals(LocalHostStringLookup.
INSTANCE.lookup("address"),
-InetAddress.getLocalHost().getHostAddress());
+Assert.assertEquals(InetAddress.getLocalHost().getHostAddress(),
+LocalHostStringLookup.INSTANCE.lookup("address"));
  }

  @Test
  public void testCanonicalName() throws UnknownHostException {
-Assert.assertEquals(LocalHostStringLookup.
INSTANCE.lookup("canonical-name"),
-InetAddress.getLocalHost().getCanonicalHostName());
+Assert.assertEquals(InetAddress.getLocalHost().
getCanonicalHostName(),
+LocalHostStringLookup.INSTANCE.lookup("canonical-name"));
  }

  @Test
  public void testName() throws UnknownHostException {
-Assert.assertEquals(LocalHostStringLookup.INSTANCE.lookup("name"),
InetAddress.getLocalHost().getHostName());
+Assert.assertEquals(InetAddress.getLocalHost().getHostName(),
+LocalHostStringLookup.INSTANCE.lookup("name"));
  }

  }





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

Re: [text] Update from Java 7 to Java 8?

[Pascal Schumacher]

Am 13.02.2018 um 23:14 schrieb Gary Gregory:

What about:

- Release 1.3 as is WRT Java, which is Java 7
- Switch to Java 8 for 1.4.


Fine with me.

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

Re: [text] Adapt the Log4j 2 Interpolator to [text]

[Pascal Schumacher]

Am 12.02.2018 um 21:53 schrieb Gary Gregory:

On Mon, Feb 12, 2018 at 12:53 PM, Gary Gregory <garydgreg...@gmail.com>
wrote:


On Mon, Feb 12, 2018 at 12:30 PM, Pascal Schumacher <
pascalschumac...@gmx.net> wrote:


please revert "Update actual Checkstyle from 6.19 to 8.8.", as Checkstyle
7+ requries Java 8+.


Done.


Thanks!

and please fix the findbugs violation:

[INFO] --- findbugs-maven-plugin:3.0.5:check(default-cli)@
commons-text---
[INFO] BugInstance size is 1
[INFO] Error size is 0
[INFO] Total bugs: 1
[INFO] org.apache.commons.text.StringTokenizer.clone() does not call
super.clone() [org.apache.commons.text.StringTokenizer] At
StringTokenizer.java:[lines 1138-1140] CN_IDIOM_NO_SUPER_CALL


But super.clone() is called, from another method...


And findbugs does not complain about the same code in StrTokenizer. What?


For StrTokenizer there is an exclusion in fb-excludes.xml.

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

Re: [text] Update from Java 7 to Java 8?

[Pascal Schumacher]

What about now? :-)

Am 12.02.2018 um 20:53 schrieb Gary Gregory:

When?

Gary




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

[text] Deprecation of StrMatcher/StrBuilder/StrTokenizer classes

[Pascal Schumacher]

Hello everybody,

after further consideration I'm not sure if it is a good idea to 
deprecate StrMatcher (to convert it to an interface and make the naming 
match *StringLookup), as this means that StrBuilder and StrTokenizer 
also have to be deprecated.


Not long ago we told users of these classes to migrate from commons-lang 
to commons-text. Now they have to migrate again. Seems a bit much imho.


What do you think?

Cheers,

Pascal





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

Re: [text] Adapt the Log4j 2 Interpolator to [text]

[Pascal Schumacher]

Am 12.02.2018 um 18:52 schrieb Gary Gregory:

I agree 100% and will proceed. I thought about it overnight and it does not
make sense to leave a mix of abstract classes and interfaces in
StrSubstitutor.


+1, but

please revert "Update actual Checkstyle from 6.19 to 8.8.", as 
Checkstyle 7+ requries Java 8+.


and please fix the findbugs violation:

[INFO] --- findbugs-maven-plugin:3.0.5:check(default-cli)@ commons-text---
[INFO] BugInstance size is 1
[INFO] Error size is 0
[INFO] Total bugs: 1
[INFO] org.apache.commons.text.StringTokenizer.clone() does not call 
super.clone() [org.apache.commons.text.StringTokenizer] At 
StringTokenizer.java:[lines 1138-1140] CN_IDIOM_NO_SUPER_CALL


to fix the travis build.

Thanks,
Pascal

Re: [text] Adapt the Log4j 2 Interpolator to [text]

[Pascal Schumacher]

Am 11.02.2018 um 19:24 schrieb Gary Gregory:

I'd like a code review and then a release of 1.3. Right now we only depend
on java.base and Commons Lang, so let's keep it that way for 1.3 I think.

My comments:
- Given "TEXT-80: StrLookup API confusing generic type parameter" I 
think we should deprecate the old StrLookup class and mark it for 
removal in commons-text 2.0.

- DateStringLookup: should we use FastDateFormat?
- AbstractStringLookup: empty class, I would therefore remove it.
- StringLookupFactory: should this be a static factory, to make it 
easier to use?



(I almost added Log4j's JNDI lookup but I know that will not work on
Android so I'd like to leave stuff like that for later, maybe in a
different module.)

+1 for leaving it out

-Pascal

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

Re: [text] Adapt the Log4j 2 Interpolator to [text]

[Pascal Schumacher]

Am 11.02.2018 um 19:10 schrieb Gary Gregory:

Done but there is one checkstyle "Error" left for a TODO comment I left in
the code.


Thanks!

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

Re: [text] Adapt the Log4j 2 Interpolator to [text]

[Pascal Schumacher]

Hi Gary,

thanks for adding this, looks useful. +1

Please fix the checkstyle violations.

Thanks!

- Pascal

Am 11.02.2018 um 01:32 schrieb Gary Gregory:

On Sat, Feb 10, 2018 at 12:44 PM, Gary Gregory 
wrote:


I created the ticket "[TEXT-113] Add an interpolator string lookup." and
committed a working version with unit tests.

Please note:
- The code is in a new package  o.a.c.t.lookup and I left the current
code as intact as possible.
- The current StrLookup and StrMatcher are abstract classes and not
interfaces. This is a problem IMO.
- I introduced an interface called o.a.c.t.lookup.StringLookup.
- I did nothing to deal with StrMatcher as I have no need for a clean
extension mechanism there.
- We could add searching for lookups with a serice loader. I do not need
this for now, so I did not bother.
- The private lookup classes in StrLookup will likely be replaced by 
o.a.c.t.lookup
classes. I did not do this yet to minimize the changes for this round.

Please review. I can use this now in a couple of projects more cleanly
instead of reusing the guts of Log4j which includes similar code.


I committed some small improvements to the Javadoc. The next element to
consider is whether to deprecate the StrSubstitutor ctors that take
StrLookup (the class) in favor of ctors that take StringLookup (the
interface).

The wrinkle there is what to do with StrSubstitutor.getVariableResolver().
First, I would add a new getter StrSubstitutor.getStringLookup() and change
this ivar from StrLookup to StringLookup. Second, would be for
StrSubstitutor.getVariableResolver()
to cast it return value to StringLookup and let that throw a
ClassCastException if the StringLookup ivar does not hold an impl of
StringLookup.

Thoughts?

Gary



Thank you,
Gary

On Thu, Dec 14, 2017 at 2:40 PM, Rob Tompkins  wrote:




On Dec 14, 2017, at 4:11 PM, Gary Gregory 

wrote:

I think I'll pick Commons Config as the starting point, unless someone

else

has a stronger POV.

+1


Gary

On Thu, Dec 14, 2017 at 12:59 PM, Jan Matèrne (jhm) 
wrote:


If I see a syntax like ${prefix:key} I could think of having a map of

"map

providers".
The source of such a map could be a file, system properties,

environment

variables, database, ldap, ...

Haven't looked at commons-configuration.
But maybe also have a look at Apache Deltaspike which supports
configurtion values via a "Datasource".

And Tamaya will also have one, I think ...


Jan




-Ursprüngliche Nachricht-
Von: Ralph Goers [mailto:ralph.go...@dslextreme.com]
Gesendet: Donnerstag, 14. Dezember 2017 16:41
An: Commons Developers List
Betreff: Re: [text] Adapt the Log4j 2 Interpolator to [text]

Yes, the Interpolator was borrowed from Commons Configuration.

Ralph


On Dec 14, 2017, at 5:20 AM, Jörg Schaible  wrote:

Hi Gary,

Am Wed, 13 Dec 2017 15:17:56 -0700 schrieb Gary Gregory:


Hi All,

Log4j 2 provides it's own copy of our StrSubstitutor/StrLookup
framework enhanced for Log4j's needs. In addition it provides a
custom StrLookup called Interpolator which allows for lookups like:

${sys:java.version} and ${env:MY_VAR} to look up system properties
and environment variables respectively as well as other sub maps.

You will find this also in commons-configurations.


I would like to borrow this concept of a composite and keyed
StrLookup and make it a first class citizen in [text].

This would look like this:

Interpolator interpolator = new o.a.c.t.Interpolator();
interpolator.put("gary", StrLookup.mapLookup(new HashMap()));
interpolator.put("alice", StrLookup.mapLookup(new HashMap()));
StrSubstitutor strSubstitutor = new StrSubstitutor(interpolator);

Thoughts?

Cheers,
Jörg




-

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





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



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



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





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

Re: CP43 and Java 6

[Pascal Schumacher]

Am 04.02.2018 um 12:57 schrieb sebb:

What is the failure message?


[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile 
(default-compile) on project commons-email: Compilation failure -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to 
execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile 
(default-compile) on project commons-email: Compilation failure
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:213)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:146)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
    at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build 
(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)

    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native 
Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)

    at java.lang.reflect.Method.invoke (Method.java:564)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:229)
    at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:356)
Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: 
Compilation failure
    at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute 
(AbstractCompilerMojo.java:1165)
    at org.apache.maven.plugin.compiler.CompilerMojo.execute 
(CompilerMojo.java:168)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:134)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:146)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
    at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build 
(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)

    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native 
Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)

    at java.lang.reflect.Method.invoke (Method.java:564)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:229)
    at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:356)

Have you set up the JAVA_1_6_HOME env variable for use with the
java-1.6 profile?


No I didn't, so I guess that is the cause (do not have java 6 installed 
anymore).




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

Re: CP43 and Java 6 (was: svn commit: r1822088 - /commons/proper/email/trunk/pom.xml)

[Pascal Schumacher]

Am 25.01.2018 um 15:44 schrieb sebb:

Have you tried CP43 using Java 7 and -Pjava-1.6 ?
I tried to run "mvn clean test -Pjava-1.6" on java 7 but it causes a 
compilation failure (on helpful output is displayed even when I add "-X").


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

Re: CP43 and Java 6 (was: svn commit: r1822088 - /commons/proper/email/trunk/pom.xml)

[Pascal Schumacher]

You are right. Just revert my revert.

Sorry,
Pascal

Am 25. Januar 2018 17:50:41 MEZ schrieb Gary Gregory <garydgreg...@gmail.com>:
>On Thu, Jan 25, 2018 at 9:35 AM, Pascal Schumacher
><pascalschumac...@gmx.net
>> wrote:
>
>> No I have not.
>>
>> I expect to be able to build projects with a source and target level
>of
>> java 6 on java 6.
>>
>
>That's a bit unrealistic now that we are seeing Java 10 EAs. The tools
>have
>moved on.
>
>Gary
>
>
>>
>> Am 25. Januar 2018 15:44:10 MEZ schrieb sebb <seb...@gmail.com>:
>> >On 25 January 2018 at 14:04, Pascal Schumacher
>> ><pascalschumac...@gmx.net> wrote:
>> >> commons parent 43 includes maven plugins which require java 7
>> >
>> >Have you tried CP43 using Java 7 and -Pjava-1.6 ?
>> >
>> >> Am 25. Januar 2018 12:44:49 MEZ schrieb sebb <seb...@gmail.com>:
>> >>>On 24 January 2018 at 08:35,  <pascalschumac...@apache.org> wrote:
>> >>>> Author: pascalschumacher
>> >>>> Date: Wed Jan 24 08:35:29 2018
>> >>>> New Revision: 1822088
>> >>>>
>> >>>> URL: http://svn.apache.org/viewvc?rev=1822088=rev
>> >>>> Log:
>> >>>> revert "Update commons-parent from 42 to 43." because this
>breaks
>> >the
>> >>>build on java 6
>> >>>
>> >>>What exactly do you mean here?
>> >>>
>> >>>There are two ways to compile of Java 6:
>> >>>
>> >>>Build with Java 6
>> >>>Build with a later version, but use the profile: -Pjava-1.6
>> >>>
>> >>>What was the issue?
>> >>>If the latter breaks, then I think it is a bug in CP43
>> >>>
>>
>>>>-
>> >>>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >>>For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>>
>>-
>> >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >For additional commands, e-mail: dev-h...@commons.apache.org
>>

Re: CP43 and Java 6 (was: svn commit: r1822088 - /commons/proper/email/trunk/pom.xml)

[Pascal Schumacher]

No I have not.

I expect to be able to build projects with a source and target level of java 6 
on java 6.

Am 25. Januar 2018 15:44:10 MEZ schrieb sebb <seb...@gmail.com>:
>On 25 January 2018 at 14:04, Pascal Schumacher
><pascalschumac...@gmx.net> wrote:
>> commons parent 43 includes maven plugins which require java 7
>
>Have you tried CP43 using Java 7 and -Pjava-1.6 ?
>
>> Am 25. Januar 2018 12:44:49 MEZ schrieb sebb <seb...@gmail.com>:
>>>On 24 January 2018 at 08:35,  <pascalschumac...@apache.org> wrote:
>>>> Author: pascalschumacher
>>>> Date: Wed Jan 24 08:35:29 2018
>>>> New Revision: 1822088
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1822088=rev
>>>> Log:
>>>> revert "Update commons-parent from 42 to 43." because this breaks
>the
>>>build on java 6
>>>
>>>What exactly do you mean here?
>>>
>>>There are two ways to compile of Java 6:
>>>
>>>Build with Java 6
>>>Build with a later version, but use the profile: -Pjava-1.6
>>>
>>>What was the issue?
>>>If the latter breaks, then I think it is a bug in CP43
>>>
>>>-
>>>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>For additional commands, e-mail: dev-h...@commons.apache.org
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org

Re: CP43 and Java 6 (was: svn commit: r1822088 - /commons/proper/email/trunk/pom.xml)

[Pascal Schumacher]

commons parent 43 includes maven plugins which require java 7

Am 25. Januar 2018 12:44:49 MEZ schrieb sebb :
>On 24 January 2018 at 08:35,   wrote:
>> Author: pascalschumacher
>> Date: Wed Jan 24 08:35:29 2018
>> New Revision: 1822088
>>
>> URL: http://svn.apache.org/viewvc?rev=1822088=rev
>> Log:
>> revert "Update commons-parent from 42 to 43." because this breaks the
>build on java 6
>
>What exactly do you mean here?
>
>There are two ways to compile of Java 6:
>
>Build with Java 6
>Build with a later version, but use the profile: -Pjava-1.6
>
>What was the issue?
>If the latter breaks, then I think it is a bug in CP43
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org

Re: Drop dist entries for dormant components?

[Pascal Schumacher]

+1

Am 20.01.2018 um 15:28 schrieb sebb:

The following directories under dist [1] relate to dormant components:

attributes
discovery
el
launcher
modeler
primitives
transaction

Since these are not being developed [2], I guess we should drop them.
The code will still be available from the archives.

[1] https://dist.apache.org/repos/dist/release/commons/
[2]  http://www.apache.org/legal/release-policy.html#when-to-archive

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




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

Re: [All] Source compatibility policy

[Pascal Schumacher]

Am 16.01.2018 um 00:06 schrieb Gary Gregory:

For me, breaking source compatibility should be limited to what can be
adjusted to in my sources very easily. I would also consider whether the
breaks are for a cosmetic reasons for an actual bug fix. I would probably
pass on cosmetic breaks within minor releases.

In this case, an exception declared unnecessarily can make client code more
cumbersome, but not always, if other parts of the code happen to throw the
same exception.

More important is binary compatibility, which we should not break within
minor releases. What happens in this case to BC?


"Changes to the |throws| clause of methods or constructors do not break 
compatibility with pre-existing binaries; these clauses are checked only 
at compile time."


Source: 
https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.21


Clirr does not report any errors or warnings.

[All] Source compatibility policy

[Pascal Schumacher]

Hello,

what is our policy regarding source incompatible changes to our APIs?

Context: This commons io pull request: 
https://github.com/apache/commons-io/pull/54/files propose removing 
unnecessary throws declarations from public method signatures.


Thanks,

Pascal


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

Re: [Net] When should we update net from Java 6 to 7?

[Pascal Schumacher]

Am 13.01.2018 um 01:31 schrieb Gilles:

On Fri, 12 Jan 2018 21:51:58 +0100, Pascal Schumacher wrote:

imho we should drop support for java 6 and make every component java 7+


Why?


Imho old java versions discourage contributions. Java 7 was released in 
2011 8 (and Java 8 in 2014), so there is an increasing number of 
developers who never used older versions. Why force volunteers to work 
harder to stay Java 6 compatible when volunteering is supposed to be fun?


Support for Java 6 (and even Java 7) is decreasing everywhere. E.g. 
current maven versions (and maven plugin versions) required Java 7 
(plugin versions supporting Java 6 often do not work on Java 9). Current 
travis VMs do not support build on Java 6...


Just my two cents.

Cheers,
Pascal

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

Re: [Net] When should we update net from Java 6 to 7?

[Pascal Schumacher]

imho we should drop support for java 6 and make every component java 7+

Am 12.01.2018 um 18:54 schrieb Gary Gregory:

Hi All:

When should we update Commons Net from Java 6 to 7?

Gary




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

Re: [lang] new IllegalArgumentException shorcut.

[Pascal Schumacher]

Hi Gary,

we already have Validate#isTrue(boolean expression, String message, 
Object... values), which throws an IllegalArgumentException when the 
expression is false.


Cheers,
Pascal

Am 12.01.2018 um 18:30 schrieb Gary Gregory:

Hi All:

We have code like:

throw new IllegalArgumentException(String.format("Minimum abbreviation
width is %d", minAbbrevWidth));

and I use this pattern a lot.

I would like to short cut this as follows:

throw IllegalArgumentExceptions.format("Minimum abbreviation width is %d",
minAbbrevWidth);

with a new factory class o.a.c.l.exceptions.IllegalArgumentExceptions

Thoughts?

Gary




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

[lang] - Pull Requests containing new StringUtils methods

[Pascal Schumacher]

Hello everybody,

currently there are three open pull requests containing new StringUtils 
methods:


1. astIndexOfAnyChar

https://github.com/apache/commons-lang/pull/273

2. extendIfNotBlank/extendIfNotEmpty

https://github.com/apache/commons-lang/pull/278

https://issues.apache.org/jira/browse/LANG-1345

3. indexesOf

https://github.com/apache/commons-lang/pull/294

Merge or reject? Any opinions?

Cheers,

Pascal