[crypto] Release Build Requirements

2020-07-17 Thread Alex Remily 
Gary,

I compiled the 64-bit Windows build on my Mac and tested it in a
Windows VM.  It was fairly straightforward with mingw.  I still need
to cross-compile the Linux builds, but I'm cautiously optimistic that
they will be trivial compared to the Windows cross compilation.
Everything is easier on Linux.  Where do we go from here in terms of
getting a release out?  I see a couple of paths forward.  One, I could
work with you to get the build out on your machine; or, two, you could
work with me to get the build out on my machine.  I'm new to this
process, so defer to your judgement without recommendation.

Alex

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

Re: [VOTE] Release Apache Commons Geometry 1.0-beta1 based on RC3

2020-07-17 Thread Gilles Sadowski 
Hello.

Le jeu. 16 juil. 2020 à 06:08, Matt Juntunen
 a écrit :
>
> We have been working hard to prepare Apache Commons Geometry for an initial 
> release, so I would like to release Apache Commons Geometry (full 
> distribution) 1.0-beta1.
>
> Apache Commons Geometry 1.0-beta1 RC3 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-beta1-RC3 
> (svn revision 40506)
>
> The Git tag commons-geometry-1.0-beta1-rc3 commit for this RC is 
> c47308d13c371652d9798037b390676c13564e48 which you may browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=commit;h=c47308d13c371652d9798037b390676c13564e48
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-geometry.git 
> --branch commons-geometry-1.0-beta1-rc3 commons-geometry-1.0-beta1-rc3
>
> Maven artifacts are here:
>  
> https://repository.apache.org/content/repositories/orgapachecommons-1507/org/apache/commons/
>
> These are the artifacts and their hashes:
>
> commons-geometry-1.0-beta1-bin.tar.gz=8e63882e065b98c7868b5e336af86f4ef9892984139964d433a3602332c73e50c1c330318c5ebf17c1cd986a2d8070f73ac2d64e031416f6acc050e4ba24b396
> commons-geometry-1.0-beta1-bin.zip=da33d5a71526d37cc1d2cea922d492d8a398998c976c86641fa91b345220a39bf502674b2315ed7551ef49218e681526adf322ef0f44debdd9b6edf885e8fee0
> commons-geometry-1.0-beta1-src.tar.gz=7ff83710326aba6c852b717b948a32dc4cb182d440bc0fd15386413fa92986b7fe0b4cca70c691f1088a1e6a1de1b13e9ecb063a042591486513d420f31cba8d
> commons-geometry-1.0-beta1-src.zip=eb661af7c5b2dab0b8785d5a63348ec154fa56e2b0577867a9ad8f27d31ee6ba07e537e91386d63f8f299bac4c4cbc39ae7367ac1c70724337e44994bb76e9da
>
> (no need for .asc hashes!)
>
> I have tested this with ***'mvn clean install site 
> -Pcommons-geometry-examples'*** using:
> ***
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 
> 2018-02-24T14:49:05-05:00)
> Maven home: /home/matt/tools/maven/apache-maven-3.5.3
> Java version: 1.8.0_252, vendor: Private Build
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-40-generic", arch: "amd64", family: "unix"
>
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 
> 2018-02-24T14:49:05-05:00)
> Maven home: /home/matt/tools/maven/apache-maven-3.5.3
> Java version: 13, vendor: Oracle Corporation
> Java home: /home/matt/lang/java/jdk-13
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-40-generic", arch: "amd64", family: "unix"
>
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: 
> C:\Users\matt\tools\apache-maven-3.6.3-bin\apache-maven-3.6.3\bin\..
> Java version: 1.8.0_242, vendor: AdoptOpenJDK, runtime: C:\Program 
> Files\AdoptOpenJDK\jdk-8.0.242.08-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> ***
>
> Details of changes are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-beta1-RC3/RELEASE-NOTES.txt
> 
> https://home.apache.org/~mattjuntunen/commons-geometry-1.0-beta1-rc3-site/changes-report.html
>
> Site:
> 
> https://home.apache.org/~mattjuntunen/commons-geometry-1.0-beta1-rc3-site/index.html
> (note some *relative* links are broken and the 1.0-beta1 directories are 
> not yet created - these will be OK once the site is deployed.)
>
> CLIRR Report:
> N/A
>
> JApiCmp Report:
> N/A
>
> RAT Report:
> 
> https://home.apache.org/~mattjuntunen/commons-geometry-1.0-beta1-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.
>
   [X] +1 Release these artifacts

Builds fine with Java 8 and Java 11 on Debian GNU/Linux.
Great code coverage.

Thanks,
Gilles

>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Matt Juntunen,
> Release Manager (using key 7DD53AEFEDF1C3D392B51EBE346F4FCECFB70B1A)
>
> 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-geometry.git --branch 
> commons-geometry-1.0-beta1-rc3 commons-geometry-1.0-beta1-rc3
> cd commons-geometry-1.0-beta1-rc3
>
> 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 mus

Re: [VOTE] Release Apache Commons Geometry 1.0-beta1 based on RC3

2020-07-17 Thread Rob Tompkins 
+1 ... Good work...keep it up :-)

Checked signatures
Checked reports,
Checked build with java 8 and java 11

All checks out

-Rob

> On Jul 16, 2020, at 12:08 AM, Matt Juntunen  wrote:
> 
> We have been working hard to prepare Apache Commons Geometry for an initial 
> release, so I would like to release Apache Commons Geometry (full 
> distribution) 1.0-beta1.
> 
> Apache Commons Geometry 1.0-beta1 RC3 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-beta1-RC3 (svn 
> revision 40506)
> 
> The Git tag commons-geometry-1.0-beta1-rc3 commit for this RC is 
> c47308d13c371652d9798037b390676c13564e48 which you may browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=commit;h=c47308d13c371652d9798037b390676c13564e48
> You may checkout this tag using:
>git clone https://gitbox.apache.org/repos/asf/commons-geometry.git 
> --branch commons-geometry-1.0-beta1-rc3 commons-geometry-1.0-beta1-rc3
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1507/org/apache/commons/
> 
> These are the artifacts and their hashes:
> 
> commons-geometry-1.0-beta1-bin.tar.gz=8e63882e065b98c7868b5e336af86f4ef9892984139964d433a3602332c73e50c1c330318c5ebf17c1cd986a2d8070f73ac2d64e031416f6acc050e4ba24b396
> commons-geometry-1.0-beta1-bin.zip=da33d5a71526d37cc1d2cea922d492d8a398998c976c86641fa91b345220a39bf502674b2315ed7551ef49218e681526adf322ef0f44debdd9b6edf885e8fee0
> commons-geometry-1.0-beta1-src.tar.gz=7ff83710326aba6c852b717b948a32dc4cb182d440bc0fd15386413fa92986b7fe0b4cca70c691f1088a1e6a1de1b13e9ecb063a042591486513d420f31cba8d
> commons-geometry-1.0-beta1-src.zip=eb661af7c5b2dab0b8785d5a63348ec154fa56e2b0577867a9ad8f27d31ee6ba07e537e91386d63f8f299bac4c4cbc39ae7367ac1c70724337e44994bb76e9da
> 
> (no need for .asc hashes!)
> 
> I have tested this with ***'mvn clean install site 
> -Pcommons-geometry-examples'*** using:
> ***
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 
> 2018-02-24T14:49:05-05:00)
> Maven home: /home/matt/tools/maven/apache-maven-3.5.3
> Java version: 1.8.0_252, vendor: Private Build
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-40-generic", arch: "amd64", family: "unix"
> 
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 
> 2018-02-24T14:49:05-05:00)
> Maven home: /home/matt/tools/maven/apache-maven-3.5.3
> Java version: 13, vendor: Oracle Corporation
> Java home: /home/matt/lang/java/jdk-13
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-40-generic", arch: "amd64", family: "unix"
> 
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: 
> C:\Users\matt\tools\apache-maven-3.6.3-bin\apache-maven-3.6.3\bin\..
> Java version: 1.8.0_242, vendor: AdoptOpenJDK, runtime: C:\Program 
> Files\AdoptOpenJDK\jdk-8.0.242.08-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> ***
> 
> Details of changes are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-beta1-RC3/RELEASE-NOTES.txt
>
> https://home.apache.org/~mattjuntunen/commons-geometry-1.0-beta1-rc3-site/changes-report.html
> 
> Site:
>
> https://home.apache.org/~mattjuntunen/commons-geometry-1.0-beta1-rc3-site/index.html
>(note some *relative* links are broken and the 1.0-beta1 directories are 
> not yet created - these will be OK once the site is deployed.)
> 
> CLIRR Report:
>N/A
> 
> JApiCmp Report:
>N/A
> 
> RAT Report:
>
> https://home.apache.org/~mattjuntunen/commons-geometry-1.0-beta1-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,
> 
> Matt Juntunen,
> Release Manager (using key 7DD53AEFEDF1C3D392B51EBE346F4FCECFB70B1A)
> 
> 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-geometry.git --branch 
> commons-geometry-1.0-beta1-rc3 commons-geometry-1.0-beta1-rc3
> cd commons-geometry-1.0-beta1-rc3
> 
> 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 includ

Re: Proposal for creating a CompositeException in ExceptionUtils

2020-07-17 Thread Adwait Kumar Singh 
Sample use cases:
1. Perform multiple operations, some failed due to different reasons.
Return a CompositeException for the failed ones.
2. Do a validation on some input. I want to collect all different failures,
I can throw a CompositeException.
3. In some cases the exception had occurred earlier, and we want to throw
all such exceptions. For example failures caused by Java Agent, some java
agents store such failures. During actual execution I want to throw all
such exceptions.

Basically any such scenarios where there are multiple causes for failure
and I want to throw all of them.

On Fri, Jul 17, 2020 at 10:06 PM sebb  wrote:

> What is the use case for this?
>
> On Fri, 17 Jul 2020 at 16:29, Adwait Kumar Singh
>  wrote:
> >
> > Yes Gary, something similar. However it would differ from IOExceptionList
> > which creates an aggregated message of all exceptions but loses the
> > stacktrace via getCause or printStackTrace.
> >
> > To be precise, this is exactly what I am taking about
> >
> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/exceptions/CompositeException
> .
> > <
> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/exceptions/CompositeException.java
> >
> >
> > Created a JIRA issue 
> for
> > the same.
> >
> > <
> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/exceptions/CompositeException.java
> >
> >
> > On Fri, Jul 17, 2020 at 8:44 PM Gary Gregory 
> wrote:
> >
> > > Would it be like Common IO's IOExceptionList or Commons DBCP
> > > SQLExceptionList ?
> > >
> > > Gary
> > >
> > > On Fri, Jul 17, 2020 at 11:01 AM Adwait Kumar Singh <
> > > theadvaitkumarsi...@gmail.com> wrote:
> > >
> > > > To be more specific, I meant a util function in ExceptionUtils. Like
> > > this,
> > > >
> > > > ExceptionUtils.createCompositeException(String overallErrorMessage,
> > > > Throwable... throwables)
> > > >
> > > > This would return a CompositeException which would contain all the
> > > > Throwables and whose getCause() and printStackTrace() methods have
> been
> > > > overridden to given out a verbose cause and stacktrace which would
> be an
> > > > aggregation of the throwables supplied.
> > > >
> > > > Pardon me if this is not the correct platform or right mechanism to
> > > propose
> > > > such changes. Please let me know the correct way to proceed.
> > > >
> > > > Thanks,
> > > > Adwait.
> > > >
> > > > On Fri, Jul 17, 2020 at 5:18 PM Adwait Kumar Singh <
> > > > theadvaitkumarsi...@gmail.com> wrote:
> > > >
> > > > > Hi Commons devs,
> > > > >
> > > > > Use case : Ability to a single exceptions with multiple causes.
> This
> > > > > required in validation or initialization scenarios for example
> when I
> > > > want
> > > > > to Validation/Initialization failures for multiple reasons and each
> > > > reason
> > > > > having a unique cause.
> > > > > RxJava provides something similar
> > > > > <
> > > >
> > >
> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/exceptions/CompositeException.java
> > > > >
> > > > > .
> > > > >
> > > > > Wanted to know if this makes sense, would raise a PR if it does.
> > > > >
> > > > > Thanks,
> > > > > Adwait.
> > > > >
> > > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Proposal for creating a CompositeException in ExceptionUtils

2020-07-17 Thread sebb 
What is the use case for this?

On Fri, 17 Jul 2020 at 16:29, Adwait Kumar Singh
 wrote:
>
> Yes Gary, something similar. However it would differ from IOExceptionList
> which creates an aggregated message of all exceptions but loses the
> stacktrace via getCause or printStackTrace.
>
> To be precise, this is exactly what I am taking about
> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/exceptions/CompositeException.
> 
>
> Created a JIRA issue  for
> the same.
>
> 
>
> On Fri, Jul 17, 2020 at 8:44 PM Gary Gregory  wrote:
>
> > Would it be like Common IO's IOExceptionList or Commons DBCP
> > SQLExceptionList ?
> >
> > Gary
> >
> > On Fri, Jul 17, 2020 at 11:01 AM Adwait Kumar Singh <
> > theadvaitkumarsi...@gmail.com> wrote:
> >
> > > To be more specific, I meant a util function in ExceptionUtils. Like
> > this,
> > >
> > > ExceptionUtils.createCompositeException(String overallErrorMessage,
> > > Throwable... throwables)
> > >
> > > This would return a CompositeException which would contain all the
> > > Throwables and whose getCause() and printStackTrace() methods have been
> > > overridden to given out a verbose cause and stacktrace which would be an
> > > aggregation of the throwables supplied.
> > >
> > > Pardon me if this is not the correct platform or right mechanism to
> > propose
> > > such changes. Please let me know the correct way to proceed.
> > >
> > > Thanks,
> > > Adwait.
> > >
> > > On Fri, Jul 17, 2020 at 5:18 PM Adwait Kumar Singh <
> > > theadvaitkumarsi...@gmail.com> wrote:
> > >
> > > > Hi Commons devs,
> > > >
> > > > Use case : Ability to a single exceptions with multiple causes. This
> > > > required in validation or initialization scenarios for example when I
> > > want
> > > > to Validation/Initialization failures for multiple reasons and each
> > > reason
> > > > having a unique cause.
> > > > RxJava provides something similar
> > > > <
> > >
> > https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/exceptions/CompositeException.java
> > > >
> > > > .
> > > >
> > > > Wanted to know if this makes sense, would raise a PR if it does.
> > > >
> > > > Thanks,
> > > > Adwait.
> > > >
> > >
> >

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

Re: Proposal for creating a CompositeException in ExceptionUtils

2020-07-17 Thread Adwait Kumar Singh 
Yes Gary, something similar. However it would differ from IOExceptionList
which creates an aggregated message of all exceptions but loses the
stacktrace via getCause or printStackTrace.

To be precise, this is exactly what I am taking about
https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/exceptions/CompositeException.


Created a JIRA issue  for
the same.



On Fri, Jul 17, 2020 at 8:44 PM Gary Gregory  wrote:

> Would it be like Common IO's IOExceptionList or Commons DBCP
> SQLExceptionList ?
>
> Gary
>
> On Fri, Jul 17, 2020 at 11:01 AM Adwait Kumar Singh <
> theadvaitkumarsi...@gmail.com> wrote:
>
> > To be more specific, I meant a util function in ExceptionUtils. Like
> this,
> >
> > ExceptionUtils.createCompositeException(String overallErrorMessage,
> > Throwable... throwables)
> >
> > This would return a CompositeException which would contain all the
> > Throwables and whose getCause() and printStackTrace() methods have been
> > overridden to given out a verbose cause and stacktrace which would be an
> > aggregation of the throwables supplied.
> >
> > Pardon me if this is not the correct platform or right mechanism to
> propose
> > such changes. Please let me know the correct way to proceed.
> >
> > Thanks,
> > Adwait.
> >
> > On Fri, Jul 17, 2020 at 5:18 PM Adwait Kumar Singh <
> > theadvaitkumarsi...@gmail.com> wrote:
> >
> > > Hi Commons devs,
> > >
> > > Use case : Ability to a single exceptions with multiple causes. This
> > > required in validation or initialization scenarios for example when I
> > want
> > > to Validation/Initialization failures for multiple reasons and each
> > reason
> > > having a unique cause.
> > > RxJava provides something similar
> > > <
> >
> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/exceptions/CompositeException.java
> > >
> > > .
> > >
> > > Wanted to know if this makes sense, would raise a PR if it does.
> > >
> > > Thanks,
> > > Adwait.
> > >
> >
>

Re: Proposal for creating a CompositeException in ExceptionUtils

2020-07-17 Thread Gary Gregory 
Would it be like Common IO's IOExceptionList or Commons DBCP
SQLExceptionList ?

Gary

On Fri, Jul 17, 2020 at 11:01 AM Adwait Kumar Singh <
theadvaitkumarsi...@gmail.com> wrote:

> To be more specific, I meant a util function in ExceptionUtils. Like this,
>
> ExceptionUtils.createCompositeException(String overallErrorMessage,
> Throwable... throwables)
>
> This would return a CompositeException which would contain all the
> Throwables and whose getCause() and printStackTrace() methods have been
> overridden to given out a verbose cause and stacktrace which would be an
> aggregation of the throwables supplied.
>
> Pardon me if this is not the correct platform or right mechanism to propose
> such changes. Please let me know the correct way to proceed.
>
> Thanks,
> Adwait.
>
> On Fri, Jul 17, 2020 at 5:18 PM Adwait Kumar Singh <
> theadvaitkumarsi...@gmail.com> wrote:
>
> > Hi Commons devs,
> >
> > Use case : Ability to a single exceptions with multiple causes. This
> > required in validation or initialization scenarios for example when I
> want
> > to Validation/Initialization failures for multiple reasons and each
> reason
> > having a unique cause.
> > RxJava provides something similar
> > <
> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/exceptions/CompositeException.java
> >
> > .
> >
> > Wanted to know if this makes sense, would raise a PR if it does.
> >
> > Thanks,
> > Adwait.
> >
>

Re: Proposal for creating a CompositeException in ExceptionUtils

2020-07-17 Thread Adwait Kumar Singh 
To be more specific, I meant a util function in ExceptionUtils. Like this,

ExceptionUtils.createCompositeException(String overallErrorMessage,
Throwable... throwables)

This would return a CompositeException which would contain all the
Throwables and whose getCause() and printStackTrace() methods have been
overridden to given out a verbose cause and stacktrace which would be an
aggregation of the throwables supplied.

Pardon me if this is not the correct platform or right mechanism to propose
such changes. Please let me know the correct way to proceed.

Thanks,
Adwait.

On Fri, Jul 17, 2020 at 5:18 PM Adwait Kumar Singh <
theadvaitkumarsi...@gmail.com> wrote:

> Hi Commons devs,
>
> Use case : Ability to a single exceptions with multiple causes. This
> required in validation or initialization scenarios for example when I want
> to Validation/Initialization failures for multiple reasons and each reason
> having a unique cause.
> RxJava provides something similar
> 
> .
>
> Wanted to know if this makes sense, would raise a PR if it does.
>
> Thanks,
> Adwait.
>

Re: [ANNOUCEMENT] Apache Commons Lang Version 3.11

2020-07-17 Thread Rob Tompkins 
Thanks Gary!

> On Jul 17, 2020, at 9:52 AM, Gary Gregory  wrote:
> 
> The Apache Commons Lang team has released version 3.11.
> 
> This document contains the release notes for the 3.11 version of Apache
> Commons Lang.
> Commons Lang is a set of utility functions and reusable components that
> should be of use in any
> Java environment.
> 
> Lang 3.9 and onwards now targets Java 8, making use of features that
> arrived with Java 8.
> 
> For the advice on upgrading from 2.x to 3.x, see the following page:
> 
>https://commons.apache.org/lang/article3_0.html
> 
> Apache Commons Lang, a package of Java utility classes for the
> classes that are in java.lang's hierarchy, or are considered to be so
> standard as to justify existence in java.lang.
> 
> New features and bug fixes.
> 
> Changes in this version include:
> 
> New features:
> oAdd ArrayUtils.isSameLength() to compare more array types
> #430. Thanks to XenoAmess, Gary Gregory.
> oAdded the Locks class as a convenient possibility to deal with
> locked objects.
> o LANG-1568: Add to Functions: FailableBooleanSupplier,
> FailableIntSupplier, FailableLongSupplier, FailableDoubleSupplier, and so
> on.
> o LANG-1569: Add ArrayUtils.get(T[], index, T) to provide an out-of-bounds
> default value.
> o LANG-1570: Add JavaVersion enum constants for Java 14 and 15. #553.
> Thanks to Edgar Asatryan.
> oAdd JavaVersion enum constants for Java 16. Thanks to Gary
> Gregory.
> o LANG-1556: Use Java 8 lambdas and Map operations. Thanks to XenoAmess.
> o LANG-1565: Change removeLastFieldSeparator to use endsWith #550. Thanks
> to XenoAmess.
> o LANG-1557: Change a Pattern to a static final field, for not letting it
> compile each time the function invoked. #542. Thanks to XenoAmess, Gary
> Gregory.
> oAdd ImmutablePair factory methods left() and right().
> oAdd ObjectUtils.toString(Object, Supplier).
> oAdd
> org.apache.commons.lang3.StringUtils.substringAfter(String, int).
> oAdd
> org.apache.commons.lang3.StringUtils.substringAfterLast(String, int).
> 
> Fixed Bugs:
> oFix Javadoc for StringUtils.appendIfMissingIgnoreCase() #507.
> Thanks to contextshuffling.
> o LANG-1560: Refine Javadoc #545. Thanks to XenoAmess.
> o LANG-1554: Fix typos #539. Thanks to XenoAmess.
> o LANG-1555: Ignored exception `ignored`, should not be called so #540.
> Thanks to XenoAmess.
> o LANG-1528: StringUtils.replaceEachRepeatedly gives IllegalStateException
> #505. Thanks to Edwin Delgado H.
> o LANG-1543: [JSON string for maps] ToStringBuilder.reflectionToString
> doesnt render nested maps correctly. Thanks to Swaraj Pal, Wander Costa,
> Gary Gregory.
> oCorrect Javadocs of methods that use Validate.notNull() and
> replace some uses of Validate.isTrue() with Validate.notNull(). #525.
> Thanks to Isira Seneviratne.
> o LANG-1539: Add allNull() and anyNull() methods to ObjectUtils. #522.
> Thanks to Isira Seneviratne.
> 
> Changes:
> oRefine test output for FastDateParserTest Thanks to Jin Xu.
> o LANG-1549: CharSequenceUtils.lastIndexOf : remake it Thanks to Jin Xu.
> oremove encoding and docEncoding and use inherited values from
> commons-parent Thanks to XenoAmess.
> oSimplify null checks in Pair.hashCode() using
> Objects.hashCode(). #517. Thanks to Isira Seneviratne, Bruno P. Kinoshita.
> oSimplify null checks in Triple.hashCode() using
> Objects.hashCode(). #516. Thanks to Isira Seneviratne, Bruno P. Kinoshita.
> oSimplify some if statements in StringUtils. #521. Thanks to
> Isira Seneviratne, Bruno P. Kinoshita.
> o LANG-1537: Simplify a null check in the private replaceEach() method of
> StringUtils. #514. Thanks to Isira Seneviratne, Bruno P. Kinoshita.
> o LANG-1534: Replace some usages of the ternary operator with calls to
> Math.max() and Math.min() #512. Thanks to Isira Seneviratne, Bruno P.
> Kinoshita.
> o(Javadoc) Fix return tag for throwableOf*() methods #518.
> Thanks to Arend v. Reinersdorff, Bruno P. Kinoshita.
> o LANG-1545: CharSequenceUtils.regionMatches is wrong dealing with
> Georgian. Thanks to XenoAmess, Gary Gregory.
> o LANG-1550: Optimize ArrayUtils::isArrayIndexValid method. #551. Thanks to
> Edgar Asatryan.
> o LANG-1561: Use List.sort instead of Collection.sort #546. Thanks to
> XenoAmess.
> o LANG-1563: Use StandardCharsets.UTF_8 #548. Thanks to XenoAmess.
> o LANG-1564: Use Collections.singletonList insteadof Arrays.asList when
> there be only one element. #549. Thanks to XenoAmess.
> o LANG-1553: Change array style from `int a[]` to `int[] a` #537. Thanks to
> XenoAmess.
> o LANG-1552: Change from addAll to constructors for some List #536. Thanks
> to XenoAmess.
> o LANG-1558: Simplify if as some conditions are covered by others #543.
> Thanks to XenoAmess.
> o LANG-1567: Fixed Javadocs for setTestRecursive() #556. Thanks to Miguel
> Muñoz, Bruno P. Kinoshita, Gary Gregory

[ANNOUCEMENT] Apache Commons Lang Version 3.11

2020-07-17 Thread Gary Gregory 
The Apache Commons Lang team has released version 3.11.

This document contains the release notes for the 3.11 version of Apache
Commons Lang.
Commons Lang is a set of utility functions and reusable components that
should be of use in any
Java environment.

Lang 3.9 and onwards now targets Java 8, making use of features that
arrived with Java 8.

For the advice on upgrading from 2.x to 3.x, see the following page:

https://commons.apache.org/lang/article3_0.html

Apache Commons Lang, a package of Java utility classes for the
classes that are in java.lang's hierarchy, or are considered to be so
standard as to justify existence in java.lang.

New features and bug fixes.

Changes in this version include:

New features:
oAdd ArrayUtils.isSameLength() to compare more array types
#430. Thanks to XenoAmess, Gary Gregory.
oAdded the Locks class as a convenient possibility to deal with
locked objects.
o LANG-1568: Add to Functions: FailableBooleanSupplier,
FailableIntSupplier, FailableLongSupplier, FailableDoubleSupplier, and so
on.
o LANG-1569: Add ArrayUtils.get(T[], index, T) to provide an out-of-bounds
default value.
o LANG-1570: Add JavaVersion enum constants for Java 14 and 15. #553.
Thanks to Edgar Asatryan.
oAdd JavaVersion enum constants for Java 16. Thanks to Gary
Gregory.
o LANG-1556: Use Java 8 lambdas and Map operations. Thanks to XenoAmess.
o LANG-1565: Change removeLastFieldSeparator to use endsWith #550. Thanks
to XenoAmess.
o LANG-1557: Change a Pattern to a static final field, for not letting it
compile each time the function invoked. #542. Thanks to XenoAmess, Gary
Gregory.
oAdd ImmutablePair factory methods left() and right().
oAdd ObjectUtils.toString(Object, Supplier).
oAdd
org.apache.commons.lang3.StringUtils.substringAfter(String, int).
oAdd
org.apache.commons.lang3.StringUtils.substringAfterLast(String, int).

Fixed Bugs:
oFix Javadoc for StringUtils.appendIfMissingIgnoreCase() #507.
Thanks to contextshuffling.
o LANG-1560: Refine Javadoc #545. Thanks to XenoAmess.
o LANG-1554: Fix typos #539. Thanks to XenoAmess.
o LANG-1555: Ignored exception `ignored`, should not be called so #540.
Thanks to XenoAmess.
o LANG-1528: StringUtils.replaceEachRepeatedly gives IllegalStateException
#505. Thanks to Edwin Delgado H.
o LANG-1543: [JSON string for maps] ToStringBuilder.reflectionToString
doesnt render nested maps correctly. Thanks to Swaraj Pal, Wander Costa,
Gary Gregory.
oCorrect Javadocs of methods that use Validate.notNull() and
replace some uses of Validate.isTrue() with Validate.notNull(). #525.
Thanks to Isira Seneviratne.
o LANG-1539: Add allNull() and anyNull() methods to ObjectUtils. #522.
Thanks to Isira Seneviratne.

Changes:
oRefine test output for FastDateParserTest Thanks to Jin Xu.
o LANG-1549: CharSequenceUtils.lastIndexOf : remake it Thanks to Jin Xu.
oremove encoding and docEncoding and use inherited values from
commons-parent Thanks to XenoAmess.
oSimplify null checks in Pair.hashCode() using
Objects.hashCode(). #517. Thanks to Isira Seneviratne, Bruno P. Kinoshita.
oSimplify null checks in Triple.hashCode() using
Objects.hashCode(). #516. Thanks to Isira Seneviratne, Bruno P. Kinoshita.
oSimplify some if statements in StringUtils. #521. Thanks to
Isira Seneviratne, Bruno P. Kinoshita.
o LANG-1537: Simplify a null check in the private replaceEach() method of
StringUtils. #514. Thanks to Isira Seneviratne, Bruno P. Kinoshita.
o LANG-1534: Replace some usages of the ternary operator with calls to
Math.max() and Math.min() #512. Thanks to Isira Seneviratne, Bruno P.
Kinoshita.
o(Javadoc) Fix return tag for throwableOf*() methods #518.
Thanks to Arend v. Reinersdorff, Bruno P. Kinoshita.
o LANG-1545: CharSequenceUtils.regionMatches is wrong dealing with
Georgian. Thanks to XenoAmess, Gary Gregory.
o LANG-1550: Optimize ArrayUtils::isArrayIndexValid method. #551. Thanks to
Edgar Asatryan.
o LANG-1561: Use List.sort instead of Collection.sort #546. Thanks to
XenoAmess.
o LANG-1563: Use StandardCharsets.UTF_8 #548. Thanks to XenoAmess.
o LANG-1564: Use Collections.singletonList insteadof Arrays.asList when
there be only one element. #549. Thanks to XenoAmess.
o LANG-1553: Change array style from `int a[]` to `int[] a` #537. Thanks to
XenoAmess.
o LANG-1552: Change from addAll to constructors for some List #536. Thanks
to XenoAmess.
o LANG-1558: Simplify if as some conditions are covered by others #543.
Thanks to XenoAmess.
o LANG-1567: Fixed Javadocs for setTestRecursive() #556. Thanks to Miguel
Muñoz, Bruno P. Kinoshita, Gary Gregory.
o LANG-1542: ToStringBuilder.reflectionToString - Wrong JSON format when
object has a List of Enum. Thanks to Tr?n Ng?c Khoa, Gary Gregory.
oMake
org.apache.commons.lang3.CharSequenceUtils.toCharArray(CharSequence) public.
oorg.apache.commons:common

Re: [all] Thoughts on build system maven -> gradle??

2020-07-17 Thread Melloware 
I agree with Gary.   I know its been decided but I thought I would add 
my -1.


Technology better have a compelling reason to switch and in the past we 
have had:


Ant -> Maven was a big leap for convention over configuration and 
dependency management


SVN -> GIT was a big leap for the handling of branches/merging and 
collaboration.


Maven -> Gradle the only reason I constantly hear is its less verbose. 
Well Maven's verbosity is not a problem for me and switching to Groovy 
doesn't seem worth the leap.


Just my two cents!

    Mello

On 7/17/2020 9:01 AM, Gary Gregory wrote:

Hi Rob,

Even though I am on the minus side, I am glad you brought this up for
discussion. I think it helped us better understand where we are, how we got
here, and why we want to stay.

Gary



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

Re: [all] on automating signature validation (Was: Re: [VOTE] Release Apache Commons Geometry 1.0-beta1 based on RC3)

2020-07-17 Thread Rob Tompkins 
Pardon…my email threads got crossed there…a little too busy…will reply to vote 
thread.

-Rob

> On Jul 17, 2020, at 9:01 AM, Rob Tompkins  wrote:
> 
> Yes
> 
>> On Jul 17, 2020, at 7:38 AM, Matt Juntunen  wrote:
>> 
>> Hi Rob,
>> 
>> Just to be clear, your +1 is for the commons-geometry release based on rc3?
>> 
>> -Matt
>> 
>> From: Rob Tompkins 
>> Sent: Thursday, July 16, 2020 11:19 PM
>> To: Commons Developers List 
>> Subject: Re: [all] on automating signature validation (Was: Re: [VOTE] 
>> Release Apache Commons Geometry 1.0-beta1 based on RC3)
>> 
>> +1 ... Good work...keep it up :-)
>> 
>> Checked signatures
>> Checked reports,
>> Checked build with java 8 and java 11
>> 
>> All checks out
>> 
>> -Rob
>> 
>>> On Jul 16, 2020, at 8:53 PM, Rob Tompkins  wrote:
>>> 
>>> 
>>> 
 On Jul 16, 2020, at 7:43 PM, Gilles Sadowski  wrote:
 
 Hello.
 
>> Le ven. 17 juil. 2020 à 00:37, Rob Tompkins  a écrit 
>> :
> 
> Woof….lots of submodules make for hard signature validation of the maven 
> signatures.
 
 I still don't get why this check cannot be automated (cf. other thread on 
 that
 subject where the same question remained unanswered).
>>> 
>>> I’m yet working on that automation. I quite agree. Although, having the 
>>> multiple modules does require that the automation be slightly tailored to 
>>> the collection of modules, which I’m totally on board with.
>>> 
>>> Still curious to hear what MarkT may have to say there as he knows more of 
>>> the subtleties there than I do. (I may ping and ask for his advice)
>>> 
>>> -Rob
>>> 
 
> Will need time to go through all of the files in nexus….
 
 Possibly one reason why fewer and fewer people participate in votes about
 release of a component (where s/lots of submodules/lots of components/
 makes for an equally true remark)
 
> will try to get to it tonight.
 
 Thanks,
 Gilles
 
> [...]
 
 -
 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: [all] on automating signature validation (Was: Re: [VOTE] Release Apache Commons Geometry 1.0-beta1 based on RC3)

2020-07-17 Thread Rob Tompkins 
Yes

> On Jul 17, 2020, at 7:38 AM, Matt Juntunen  wrote:
> 
> Hi Rob,
> 
> Just to be clear, your +1 is for the commons-geometry release based on rc3?
> 
> -Matt
> 
> From: Rob Tompkins 
> Sent: Thursday, July 16, 2020 11:19 PM
> To: Commons Developers List 
> Subject: Re: [all] on automating signature validation (Was: Re: [VOTE] 
> Release Apache Commons Geometry 1.0-beta1 based on RC3)
> 
> +1 ... Good work...keep it up :-)
> 
> Checked signatures
> Checked reports,
> Checked build with java 8 and java 11
> 
> All checks out
> 
> -Rob
> 
>> On Jul 16, 2020, at 8:53 PM, Rob Tompkins  wrote:
>> 
>> 
>> 
>>> On Jul 16, 2020, at 7:43 PM, Gilles Sadowski  wrote:
>>> 
>>> Hello.
>>> 
> Le ven. 17 juil. 2020 à 00:37, Rob Tompkins  a écrit :
 
 Woof….lots of submodules make for hard signature validation of the maven 
 signatures.
>>> 
>>> I still don't get why this check cannot be automated (cf. other thread on 
>>> that
>>> subject where the same question remained unanswered).
>> 
>> I’m yet working on that automation. I quite agree. Although, having the 
>> multiple modules does require that the automation be slightly tailored to 
>> the collection of modules, which I’m totally on board with.
>> 
>> Still curious to hear what MarkT may have to say there as he knows more of 
>> the subtleties there than I do. (I may ping and ask for his advice)
>> 
>> -Rob
>> 
>>> 
 Will need time to go through all of the files in nexus….
>>> 
>>> Possibly one reason why fewer and fewer people participate in votes about
>>> release of a component (where s/lots of submodules/lots of components/
>>> makes for an equally true remark)
>>> 
 will try to get to it tonight.
>>> 
>>> Thanks,
>>> Gilles
>>> 
 [...]
>>> 
>>> -
>>> 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: [all] Thoughts on build system maven -> gradle??

2020-07-17 Thread Gary Gregory 
Hi Rob,

Even though I am on the minus side, I am glad you brought this up for
discussion. I think it helped us better understand where we are, how we got
here, and why we want to stay.

Gary

On Fri, Jul 17, 2020 at 7:25 AM Rob Tompkins  wrote:

> Very much appreciation guys for the thoughtful words and opinions here.
> Sounds like we’re sticking with Maven. :-)
>
> I hope everyone is doing well these days.
>
> Cheers,
> -Rob
>
> > On Jul 17, 2020, at 4:24 AM, Thomas Vandahl  wrote:
> >
> > On 17.07.20 10:13, Claude Warren wrote:
> >> -1 from me.  I have a philosophical objection.
> >
> > Same here: -1
> >
> >> Much like HTTP's mod_rewrite[1] gradle's greatest strength is that it
> >> allows the developer to do so much in so many ways.  But its greatest
> >> weakness is that it allows the developer to do so much in so many ways.
> >>
> >> My experience with Ant and Gradle is that in a fairly short period of
> time
> >> the build scripts become so complex that it takes a development team
> just
> >> to maintain them.
> >>
> >> The greatest strength of Maven is that it requires developers to
> seriously
> >> work to do things outside of the "Maven way".  But its greatest
> weakness is
> >> that developers have to seriously work  to do things outside of the
> "Maven
> >> way".
> >>
> >> My experience with Maven is that if the developer wants to do something
> >> outside of the "Maven way" it is difficult, but it also forces the
> >> developer to think about what they are doing.
> >
> > Very well put. The "Maven way" is a concept that makes it easy for new
> > people to understand how a project is structured. If you know how a
> > Maven project works in principle, you can understand all others. This is
> > one of the greatest strengths of Maven IMO.
> >
> >> With respect to this project, it is my opinion that we do not want to
> >> create a build system that is so complex that it becomes difficult for
> the
> >> uninitiated developer to contribute to the project.
> >
> > Couldn't agree more.
> >
> > Bye, Thomas
> >
> > -
> > 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
>
>

Proposal for creating a CompositeException in ExceptionUtils

2020-07-17 Thread Adwait Kumar Singh 
Hi Commons devs,

Use case : Ability to a single exceptions with multiple causes. This
required in validation or initialization scenarios for example when I want
to Validation/Initialization failures for multiple reasons and each reason
having a unique cause.
RxJava provides something similar

.

Wanted to know if this makes sense, would raise a PR if it does.

Thanks,
Adwait.

Re: [all] on automating signature validation (Was: Re: [VOTE] Release Apache Commons Geometry 1.0-beta1 based on RC3)

2020-07-17 Thread Matt Juntunen 
Hi Rob,

Just to be clear, your +1 is for the commons-geometry release based on rc3?

-Matt

From: Rob Tompkins 
Sent: Thursday, July 16, 2020 11:19 PM
To: Commons Developers List 
Subject: Re: [all] on automating signature validation (Was: Re: [VOTE] Release 
Apache Commons Geometry 1.0-beta1 based on RC3)

+1 ... Good work...keep it up :-)

Checked signatures
Checked reports,
Checked build with java 8 and java 11

All checks out

-Rob

> On Jul 16, 2020, at 8:53 PM, Rob Tompkins  wrote:
>
> 
>
>> On Jul 16, 2020, at 7:43 PM, Gilles Sadowski  wrote:
>>
>> Hello.
>>
 Le ven. 17 juil. 2020 à 00:37, Rob Tompkins  a écrit :
>>>
>>> Woof….lots of submodules make for hard signature validation of the maven 
>>> signatures.
>>
>> I still don't get why this check cannot be automated (cf. other thread on 
>> that
>> subject where the same question remained unanswered).
>
> I’m yet working on that automation. I quite agree. Although, having the 
> multiple modules does require that the automation be slightly tailored to the 
> collection of modules, which I’m totally on board with.
>
> Still curious to hear what MarkT may have to say there as he knows more of 
> the subtleties there than I do. (I may ping and ask for his advice)
>
> -Rob
>
>>
>>> Will need time to go through all of the files in nexus….
>>
>> Possibly one reason why fewer and fewer people participate in votes about
>> release of a component (where s/lots of submodules/lots of components/
>> makes for an equally true remark)
>>
>>> will try to get to it tonight.
>>
>> Thanks,
>> Gilles
>>
>>> [...]
>>
>> -
>> 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] Thoughts on build system maven -> gradle??

2020-07-17 Thread Rob Tompkins 
Very much appreciation guys for the thoughtful words and opinions here. Sounds 
like we’re sticking with Maven. :-)

I hope everyone is doing well these days.

Cheers,
-Rob

> On Jul 17, 2020, at 4:24 AM, Thomas Vandahl  wrote:
> 
> On 17.07.20 10:13, Claude Warren wrote:
>> -1 from me.  I have a philosophical objection.
> 
> Same here: -1
> 
>> Much like HTTP's mod_rewrite[1] gradle's greatest strength is that it
>> allows the developer to do so much in so many ways.  But its greatest
>> weakness is that it allows the developer to do so much in so many ways.
>> 
>> My experience with Ant and Gradle is that in a fairly short period of time
>> the build scripts become so complex that it takes a development team just
>> to maintain them.
>> 
>> The greatest strength of Maven is that it requires developers to seriously
>> work to do things outside of the "Maven way".  But its greatest weakness is
>> that developers have to seriously work  to do things outside of the "Maven
>> way".
>> 
>> My experience with Maven is that if the developer wants to do something
>> outside of the "Maven way" it is difficult, but it also forces the
>> developer to think about what they are doing.
> 
> Very well put. The "Maven way" is a concept that makes it easy for new
> people to understand how a project is structured. If you know how a
> Maven project works in principle, you can understand all others. This is
> one of the greatest strengths of Maven IMO.
> 
>> With respect to this project, it is my opinion that we do not want to
>> create a build system that is so complex that it becomes difficult for the
>> uninitiated developer to contribute to the project.
> 
> Couldn't agree more.
> 
> Bye, Thomas
> 
> -
> 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

JDK 15 is now in Rampdown Phase Two

2020-07-17 Thread Rory O'Donnell 


Hi Benedikt, **

*Per the JDK 15 schedule, we are in Rampdown Phase Two* *[1]*

Per the JDK Release Process [2] we now turn our focus to *P1 and P2 
bugs*, which can be fixed with approval [3].
Late enhancements are still possible, with approval [4], but the bar is 
now extraordinarily high.


**Please advise if you have any open high priority issues.* *

 * Schedule for JDK 15
 o 2*020/07/16 Rampdown Phase Two*
 o 2020/08/06 Initial Release Candidate
 o 2020/08/20 Final Release Candidate
 o 2020/09/15 General Availability

 * Features included in JDK 15:
 o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
   
 o JEP 360: Sealed Classes (Preview) 
 o JEP 371: Hidden Classes 
 o JEP 372: Remove the Nashorn JavaScript Engine
   
 o JEP 373: Reimplement the Legacy DatagramSocket API
   
 o JEP 374: Disable and Deprecate Biased Locking
   
 o JEP 375: Pattern Matching for instanceof (Second Preview)
   
 o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
   
 o JEP 378: Text Blocks 
 o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
   
 o JEP 381: Remove the Solaris and SPARC Ports
   
 o JEP 383: Foreign-Memory Access API (Second Incubator)
   
 o JEP 384: Records (Second Preview)
   
 o JEP 385: Deprecate RMI Activation for Removal
   

*JDK 15 **Early Access build 32 **is available**at : - jdk.java.net/15/*

These early-access, open-source builds are provided under the GNU 
General Public License, version 2, with the Classpath Exception.


 * Release notes
 o http://jdk.java.net/15/release-notes
 * Recent fixes that might be of interest
 o

   Build 32

 + 8231800: Better listing of arrays
 + 8234836: Improve serialization handling
 o Build 31
 + JDK-8248505: Unexpected NoSuchAlgorithmException when using
   secure random impl from BCFIPS provider
 o Build 29
 + JDK-8233014: Enable ShowCodeDetailsInExceptionMessages by
   default

*JDK 16 Early Access build 6 is available**at : - jdk.java.net/16/*

These early-access, open-source builds are provided under the GNU 
General Public License, version 2, with the Classpath Exception.


 * JEP Candidate
 o JEP 388: Windows/AArch64 Port 
 * JEPs proposed to target
 o JEP 347: Enable C++14 Language Features
   
 * JEPs targeted to JDK 16, so far:
 o JEP 369: Migrate to GitHub 
 o JEP 357: Migrate from Mercurial to Git
   

**

 * Recent fixes that might be of interest
 o

   Build 32

 + 8231800: Better listing of arrays
 + 8234836: Improve serialization handling
 o Build 5
 + JDK-8218021: Have jarsigner preserve posix permission attributes
 + JDK-8245302: Upgrade LogRecord to support long thread ids
   and remove its usage of ThreadLocal
 + JDK-8248505: Unexpected NoSuchAlgorithmException when using
   secure random impl from BCFIPS provider

*Cryptoroadmap updated *

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

*The "Best of the JDK" feature face-off tournament: Result!*_*
*_

 * *JDK Mission Control *is the winner based on the Twitter poll
   .

*The Quality Outreach Report for *June 2020**is available via the 
Quality Wiki page*: **June 2020 


*


*__*
Rgds,Rory

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-July/004536.html
[2] https://openjdk.java.net/jeps/3
[3] https://openjdk.java.net/jeps/3#Fix-Request-Process
[4] https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process

--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

Re: [all] Thoughts on build system maven -> gradle??

2020-07-17 Thread Thomas Vandahl 
On 17.07.20 10:13, Claude Warren wrote:
> -1 from me.  I have a philosophical objection.

Same here: -1

> Much like HTTP's mod_rewrite[1] gradle's greatest strength is that it
> allows the developer to do so much in so many ways.  But its greatest
> weakness is that it allows the developer to do so much in so many ways.
> 
> My experience with Ant and Gradle is that in a fairly short period of time
> the build scripts become so complex that it takes a development team just
> to maintain them.
> 
> The greatest strength of Maven is that it requires developers to seriously
> work to do things outside of the "Maven way".  But its greatest weakness is
> that developers have to seriously work  to do things outside of the "Maven
> way".
> 
> My experience with Maven is that if the developer wants to do something
> outside of the "Maven way" it is difficult, but it also forces the
> developer to think about what they are doing.

Very well put. The "Maven way" is a concept that makes it easy for new
people to understand how a project is structured. If you know how a
Maven project works in principle, you can understand all others. This is
one of the greatest strengths of Maven IMO.

> With respect to this project, it is my opinion that we do not want to
> create a build system that is so complex that it becomes difficult for the
> uninitiated developer to contribute to the project.

Couldn't agree more.

Bye, Thomas

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

Re: [all] Thoughts on build system maven -> gradle??

2020-07-17 Thread Claude Warren 
-1 from me.  I have a philosophical objection.

Much like HTTP's mod_rewrite[1] gradle's greatest strength is that it
allows the developer to do so much in so many ways.  But its greatest
weakness is that it allows the developer to do so much in so many ways.

My experience with Ant and Gradle is that in a fairly short period of time
the build scripts become so complex that it takes a development team just
to maintain them.

The greatest strength of Maven is that it requires developers to seriously
work to do things outside of the "Maven way".  But its greatest weakness is
that developers have to seriously work  to do things outside of the "Maven
way".

My experience with Maven is that if the developer wants to do something
outside of the "Maven way" it is difficult, but it also forces the
developer to think about what they are doing.

With respect to this project, it is my opinion that we do not want to
create a build system that is so complex that it becomes difficult for the
uninitiated developer to contribute to the project.

If the goal here is to provide a gradle build in parallel with the Maven
build then I would want to have a -1.5 vote.  Adding the extra work
associated with keeping the Gralde build sane onto the work associated with
ensuring the 2 builds provide the same output detracts further from the
goal of having a project that most experienced developers can join with
minimal effort.

Not to put too fine a point on it, but I think we want to focus on
developing, supporting and maintaining the software not developing,
supporting, and maintaining a build system to make the software.

Claude

On Fri, Jul 17, 2020 at 12:12 AM Singh, Baljit (GE Aviation, US) <
balsi...@ge.com> wrote:

> +1 from me. I prefer Gradle for two main reasons:
> - Control over how a library's dependencies are exposed ("api" vs
> "implementation", see
> https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_configurations_graph
> )
> - build.gradle is a lot simpler and a lot less verbose than pom.xml
>
> Drawback: Maven probably has a lot more plugins.
>
>
> On 7/16/20, 7:00 PM, "Alex Remily"  wrote:
>
> For those of us not as familiar with Gradle, what are some of the
> benefits?  Drawbacks?
>
> On Thu, Jul 16, 2020 at 5:30 PM Rob Tompkins 
> wrote:
> >
> > I think we might be coming towards time to make this move or at
> least accommodate for gradle builds in commons. Let’s look to the success
> the Spring Framework has had here with gradle. That said, I’m merely trying
> to gauge opinions here and am entirely content to stay with maven, if
> that’s what the community wishes.
> >
> > I’m a +1 on at least letting gradle be a part of our systems (don’t
> have to get rid of maven either).
> >
> > 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
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>


-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren