Re: [Geometry] Class "Equivalency"

[Matt Juntunen]

Gilles,

I took another look at the code and it turns out we can easily remove the 
entire Equivalency interface and just use methods of the form "eq(T, 
DoublePrecisionContext)", exactly the same way that the VectorXD classes do it 
now. This way, it's a little more clear what precision is being used for the 
comparison and we don't have an extra interface floating around. The original 
behavior can also be replicated with just "obj.eq(other, obj.getPrecision())".

WDYT?

-Matt

From: Gilles Sadowski 
Sent: Friday, January 3, 2020 8:12 PM
To: Commons Developers List 
Subject: Re: [Geometry] Class "Equivalency"

Hi.

2020-01-03 22:02 UTC+01:00, Matt Juntunen :
> Gilles,
>
> Yes, users are responsible for handling their own PrecisionContexts. The
> idea behind the Equivalency interface was to provide an easy way to perform
> "fuzzy" comparisons between objects. The interface itself does not define
> what the comparison involves. Classes that implement the interface (such as
> Line and Plane) decide what "fuzzy" means in their particular case. All of
> the current implementations of this interface contain a requirement that
> PrecisionContexts used by the compared objects (and used in floating point
> comparisons in the eq() method itself) be exactly equal in order for the
> objects to be considered equivalent. This is done to make the operation
> commutative, so that if "a.eq(b)" is true, then "b.eq(a)" is also true. This
> is documented on each implementing class.

My impression is that it is more akin to "strict" equality rather
than fuzzy.  Looking at the code, e.g. for "Line3D", it doesn't
strike as obvious what the different use-cases are for "equals"
and "eq".
In effect, I could imagine that "fuzzy" equality could not be
commutative (random, perhaps naive, thought): an instance with
low precision would indicate that some result (where precision
could have been lost) would consider itself equal to another
instance (that may have have been set with higher precision).

Gilles

>
> -Matt
> 
> From: Gilles Sadowski 
> Sent: Friday, January 3, 2020 12:56 PM
> To: Commons Developers List 
> Subject: [Geometry] Class "Equivalency"
>
> Hello.
>
> I'm wary about making that class part of the public API.
> I thought that the original idea was that users would be
> responsible of how they handle the "PrecisionContext".
> However, it seems that "Equivalency" requires equality
> of "PrecisionContext" instances (not the "double" value).
> This is non-obvious and IMHO deserves some explanation
> in the Javadoc and user guide.
>
> Regards,
> 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: [Geometry] Class "Equivalency"

[Gilles Sadowski]

Hi.

2020-01-03 22:02 UTC+01:00, Matt Juntunen :
> Gilles,
>
> Yes, users are responsible for handling their own PrecisionContexts. The
> idea behind the Equivalency interface was to provide an easy way to perform
> "fuzzy" comparisons between objects. The interface itself does not define
> what the comparison involves. Classes that implement the interface (such as
> Line and Plane) decide what "fuzzy" means in their particular case. All of
> the current implementations of this interface contain a requirement that
> PrecisionContexts used by the compared objects (and used in floating point
> comparisons in the eq() method itself) be exactly equal in order for the
> objects to be considered equivalent. This is done to make the operation
> commutative, so that if "a.eq(b)" is true, then "b.eq(a)" is also true. This
> is documented on each implementing class.

My impression is that it is more akin to "strict" equality rather
than fuzzy.  Looking at the code, e.g. for "Line3D", it doesn't
strike as obvious what the different use-cases are for "equals"
and "eq".
In effect, I could imagine that "fuzzy" equality could not be
commutative (random, perhaps naive, thought): an instance with
low precision would indicate that some result (where precision
could have been lost) would consider itself equal to another
instance (that may have have been set with higher precision).

Gilles

>
> -Matt
> 
> From: Gilles Sadowski 
> Sent: Friday, January 3, 2020 12:56 PM
> To: Commons Developers List 
> Subject: [Geometry] Class "Equivalency"
>
> Hello.
>
> I'm wary about making that class part of the public API.
> I thought that the original idea was that users would be
> responsible of how they handle the "PrecisionContext".
> However, it seems that "Equivalency" requires equality
> of "PrecisionContext" instances (not the "double" value).
> This is non-obvious and IMHO deserves some explanation
> in the Javadoc and user guide.
>
> Regards,
> 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: [Geometry] Class "Equivalency"

[Matt Juntunen]

Gilles,

Yes, users are responsible for handling their own PrecisionContexts. The idea 
behind the Equivalency interface was to provide an easy way to perform "fuzzy" 
comparisons between objects. The interface itself does not define what the 
comparison involves. Classes that implement the interface (such as Line and 
Plane) decide what "fuzzy" means in their particular case. All of the current 
implementations of this interface contain a requirement that PrecisionContexts 
used by the compared objects (and used in floating point comparisons in the 
eq() method itself) be exactly equal in order for the objects to be considered 
equivalent. This is done to make the operation commutative, so that if 
"a.eq(b)" is true, then "b.eq(a)" is also true. This is documented on each 
implementing class.

-Matt

From: Gilles Sadowski 
Sent: Friday, January 3, 2020 12:56 PM
To: Commons Developers List 
Subject: [Geometry] Class "Equivalency"

Hello.

I'm wary about making that class part of the public API.
I thought that the original idea was that users would be
responsible of how they handle the "PrecisionContext".
However, it seems that "Equivalency" requires equality
of "PrecisionContext" instances (not the "double" value).
This is non-obvious and IMHO deserves some explanation
in the Javadoc and user guide.

Regards,
Gilles

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

[RESULT][VOTE] Release Apache Commons Codec 1.14 based on RC1

[Gary Gregory]

This VOTE thread passes with the following ballots:

+1 Gary Gregory, binding
+1 Rob Tompkins, binding
+1 Bruno P. Kinoshita, binding
+0 Claude Warren, non-binding

Gary

On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory  wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Codec 1.13 was released, so I would like to release
> Apache Commons Codec 1.14.
>
> Apache Commons Codec 1.14 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1 (svn
> revision 37409)
>
> The Git tag commons-codec-1.14-RC1 commit for this RC is
> af7b94750e2178b8437d9812b28e36ac87a455f2 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=af7b94750e2178b8437d9812b28e36ac87a455f2
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-codec.git
> --branch commons-codec-1.14-RC1 commons-codec-1.14-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1483/commons-codec/commons-codec/1.14/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Mon Dec 30 19:44:19 EST 2019
>
> commons-codec-1.14-bin.tar.gz=bb21a15d0415513050d7738914b66bfe1f4612d7b44805ba208ec6d4fd923af244c98e828986cd4aa6cdcf9c78e23de981b5a34ac1abf805691a55f5be8cc0cf
>
> commons-codec-1.14-bin.zip=1119a418683ee9b599148b90056055fa93062e839ef426004c756c8054548cc1a80479f3b77a5a60c292e05ae67ae8699d46ae4ec25bad0070e17eb0e9e69756
>
> commons-codec-1.14-javadoc.jar=53dda4afcd159debd68aa8b3fdb22c6de02903e725d82203db2c8692da86091a4435664eb72df12a69e65f461712435ece81da9f0658587b2f6df3991d5a048a
>
> commons-codec-1.14-sources.jar=a0791dacf27154fa9453e16856d5b911b568eaada52a02535bb6170bdd13e97da32051d5359aa92ad0e69948450ff6f463aedc9a04f5f9ff4d5704e31e51a6b9
>
> commons-codec-1.14-src.tar.gz=1a98dc017d3213d8a89d11524683d45e9616fc6da8b4723cd1cfae23d73fefafeccc1c0f2994d1c4c52d79e1b825e4e09e601071572e2eb229105b3b4fd4a49b
>
> commons-codec-1.14-src.zip=0a7ebe348c9b12ee360e137c5bee833df4f7cfb259435ce6bda24073e8e1d3b76a202d4fd451efe29ddebcbcc31b3f7a287c7530d23bdc672129280d5c12d90e
>
> commons-codec-1.14-test-sources.jar=02c4fba74f028749abbf4bc44b328ed40fae3f60f53998dcaa2699284d337180b934ca93344271739f4e4df44643e87f7ce12dee35b252fa60f8f32ae60df460
>
> commons-codec-1.14-tests.jar=18dd09a0bd91040d857d84b0be39a482e884c701bcbbb5bbba990c80cf02d0270158bdbce8fa1b4473eeeb86d03ce1c4a3232d280f8b1356ee5c9f64d8a685a8
>
> I have tested this with:
>
> mvn -V -Duser.name=%my_apache_id%
> -Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease
> -Pjacoco -Pjapicmp -Ptest-deploy clean package site deploy
>
> using:
>
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\Java\apache-maven-3.6.3\bin\..
> Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_231\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> Details of changes since 1.13 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/index.html
> (note some *relative* links are broken and the 1.14 directories are
> not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 1.13):
>
> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-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-codec.git --branch
> commons-codec-1.14-RC1 commons-codec-1.14-RC1
> cd commons-codec-1.14-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 

[Geometry] Class "Equivalency"

[Gilles Sadowski]

Hello.

I'm wary about making that class part of the public API.
I thought that the original idea was that users would be
responsible of how they handle the "PrecisionContext".
However, it seems that "Equivalency" requires equality
of "PrecisionContext" instances (not the "double" value).
This is non-obvious and IMHO deserves some explanation
in the Javadoc and user guide.

Regards,
Gilles

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

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

[Rob Tompkins]

> On Jan 3, 2020, at 9:20 AM, Alex Herbert  wrote:
> 
> 
> 
>> On 3 Jan 2020, at 14:07, Rob Tompkins  wrote:
>> 
>> 
>> 
>>> On Jan 3, 2020, at 9:02 AM, Rob Tompkins  wrote:
>>> 
>>> 
>>> 
 On Jan 2, 2020, at 9:27 PM, Rob Tompkins  wrote:
 
 
 
> On Jan 2, 2020, at 6:55 PM, Alex Herbert  wrote:
> 
> 
> 
>> On 2 Jan 2020, at 16:53, Rob Tompkins  wrote:
>> 
>> +0 (could be convinced of +1)
>> 
>> RAT:
>> 
>> *
>> Summary
>> ---
>> Generated at: 2020-01-02T10:45:36-05:00
>> 
>> Notes: 3
>> Binaries: 4
>> Archives: 1
>> Standards: 287
>> 
>> Apache Licensed: 286
>> Generated Documents: 0
>> 
>> JavaDocs are generated, thus a license header is optional.
>> Generated files do not require license headers.
>> 
>> 1 Unknown Licenses
>> 
>> *
>> 
>> Files with unapproved licenses:
>> 
>> src/test/resources/empty.bin
>> 
>> *
> 
> Q. How did you manage to get this error?
> 
> apache-rat:check is in the default goal run by travis and 
> 'src/test/resources/empty.bin’ has been in the pom.xml exclusions for a 
> while.
> 
> I cannot reproduce this.
> 
 
 Curious. Not certain, but the build was with java 11. Let me start from 
 scratch in the morning and see if I can reproduce it. If I can indeed, 
 then I’ll send over my full mvn -version
>>> 
>>> I got this error when building from the unzipped -src.zip artifact. I’m 
>>> also getting it when I run with the environment:
>> 
>> Only in the site’s report that gets generated. It’s not in the man 
>> apache-rat:check.
> 
> OK. So the  tag should have the same config as the  tag for 
> the rat check.
> 
> Strange that the other files do not get flagged that have to be excluded in 
> the  section:
> 
> src/test/resources/bla.tar.xz
> src/test/resources/empty.bin
> src/test/resources/small.bin
> 
> 
> I’ve just run the site build myself. I guess that the empty.bin is a problem 
> as the file is empty. Rat must skip checking the file extension .bin that 
> allows it to decide that small.bin and bla.tar.xz are binary files. bla.tar 
> is detected as an archive and also ignored:
> 
> !? src/test/resources/empty.bin
>  A src/test/resources/bla.tar
>  B src/test/resources/small.bin
>  B src/test/resources/bla.tar.xz
> 
> If I duplicate the rat configuration to the  tag then this error 
> does not occur.

Right….that’s my understanding as well. It’s a minor nit, hence my +0 -> +1 
based on Gary’s opinion.

-Rob

> 
> Alex
> 
> 
>> 
>> -Rob
>> 
>>> 
>>> mvn -version
>>> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
>>> Maven home: /usr/local/Cellar/maven/3.6.3/libexec
>>> Java version: 11.0.5, vendor: Amazon.com  
>>> > >>  >> Inc., 
>>> runtime: 
>>> /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
>>> Default locale: en_US, platform encoding: UTF-8
>>> OS name: "mac os x", version: "10.15.2", arch: "x86_64", family: “mac"
>>> 
>>> Not sure if that helps.
>>> 
>>> -Rob
>>> 
 
 -Rob
 
> Gary,
> 
> I have been on holiday so have not had time to do a full RC review. I may 
> be able to do so in the next few days unless someone gets there first.
> 
> 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 Codec 1.14 based on RC1

[Alex Herbert]

> On 3 Jan 2020, at 14:07, Rob Tompkins  wrote:
> 
> 
> 
>> On Jan 3, 2020, at 9:02 AM, Rob Tompkins  wrote:
>> 
>> 
>> 
>>> On Jan 2, 2020, at 9:27 PM, Rob Tompkins  wrote:
>>> 
>>> 
>>> 
 On Jan 2, 2020, at 6:55 PM, Alex Herbert  wrote:
 
 
 
> On 2 Jan 2020, at 16:53, Rob Tompkins  wrote:
> 
> +0 (could be convinced of +1)
> 
> RAT:
> 
> *
> Summary
> ---
> Generated at: 2020-01-02T10:45:36-05:00
> 
> Notes: 3
> Binaries: 4
> Archives: 1
> Standards: 287
> 
> Apache Licensed: 286
> Generated Documents: 0
> 
> JavaDocs are generated, thus a license header is optional.
> Generated files do not require license headers.
> 
> 1 Unknown Licenses
> 
> *
> 
> Files with unapproved licenses:
> 
> src/test/resources/empty.bin
> 
> *
 
 Q. How did you manage to get this error?
 
 apache-rat:check is in the default goal run by travis and 
 'src/test/resources/empty.bin’ has been in the pom.xml exclusions for a 
 while.
 
 I cannot reproduce this.
 
>>> 
>>> Curious. Not certain, but the build was with java 11. Let me start from 
>>> scratch in the morning and see if I can reproduce it. If I can indeed, then 
>>> I’ll send over my full mvn -version
>> 
>> I got this error when building from the unzipped -src.zip artifact. I’m also 
>> getting it when I run with the environment:
> 
> Only in the site’s report that gets generated. It’s not in the man 
> apache-rat:check.

OK. So the  tag should have the same config as the  tag for 
the rat check.

Strange that the other files do not get flagged that have to be excluded in the 
 section:

src/test/resources/bla.tar.xz
src/test/resources/empty.bin
src/test/resources/small.bin


I’ve just run the site build myself. I guess that the empty.bin is a problem as 
the file is empty. Rat must skip checking the file extension .bin that allows 
it to decide that small.bin and bla.tar.xz are binary files. bla.tar is 
detected as an archive and also ignored:

!? src/test/resources/empty.bin
  A src/test/resources/bla.tar
  B src/test/resources/small.bin
  B src/test/resources/bla.tar.xz

If I duplicate the rat configuration to the  tag then this error 
does not occur.

Alex


> 
> -Rob
> 
>> 
>> mvn -version
>> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
>> Maven home: /usr/local/Cellar/maven/3.6.3/libexec
>> Java version: 11.0.5, vendor: Amazon.com  
>> > Inc., runtime: 
>> /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "mac os x", version: "10.15.2", arch: "x86_64", family: “mac"
>> 
>> Not sure if that helps.
>> 
>> -Rob
>> 
>>> 
>>> -Rob
>>> 
 Gary,
 
 I have been on holiday so have not had time to do a full RC review. I may 
 be able to do so in the next few days unless someone gets there first.
 
 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 Codec 1.14 based on RC1

[Rob Tompkins]

> On Jan 3, 2020, at 9:02 AM, Rob Tompkins  wrote:
> 
> 
> 
>> On Jan 2, 2020, at 9:27 PM, Rob Tompkins  wrote:
>> 
>> 
>> 
>>> On Jan 2, 2020, at 6:55 PM, Alex Herbert  wrote:
>>> 
>>> 
>>> 
 On 2 Jan 2020, at 16:53, Rob Tompkins  wrote:
 
 +0 (could be convinced of +1)
 
 RAT:
 
 *
 Summary
 ---
 Generated at: 2020-01-02T10:45:36-05:00
 
 Notes: 3
 Binaries: 4
 Archives: 1
 Standards: 287
 
 Apache Licensed: 286
 Generated Documents: 0
 
 JavaDocs are generated, thus a license header is optional.
 Generated files do not require license headers.
 
 1 Unknown Licenses
 
 *
 
 Files with unapproved licenses:
 
 src/test/resources/empty.bin
 
 *
>>> 
>>> Q. How did you manage to get this error?
>>> 
>>> apache-rat:check is in the default goal run by travis and 
>>> 'src/test/resources/empty.bin’ has been in the pom.xml exclusions for a 
>>> while.
>>> 
>>> I cannot reproduce this.
>>> 
>> 
>> Curious. Not certain, but the build was with java 11. Let me start from 
>> scratch in the morning and see if I can reproduce it. If I can indeed, then 
>> I’ll send over my full mvn -version
> 
> I got this error when building from the unzipped -src.zip artifact. I’m also 
> getting it when I run with the environment:

Only in the site’s report that gets generated. It’s not in the man 
apache-rat:check.

-Rob

> 
> mvn -version
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/Cellar/maven/3.6.3/libexec
> Java version: 11.0.5, vendor: Amazon.com  Inc., runtime: 
> /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.15.2", arch: "x86_64", family: “mac"
> 
> Not sure if that helps.
> 
> -Rob
> 
>> 
>> -Rob
>> 
>>> Gary,
>>> 
>>> I have been on holiday so have not had time to do a full RC review. I may 
>>> be able to do so in the next few days unless someone gets there first.
>>> 
>>> 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 Codec 1.14 based on RC1

[Rob Tompkins]

> On Jan 2, 2020, at 9:27 PM, Rob Tompkins  wrote:
> 
> 
> 
>> On Jan 2, 2020, at 6:55 PM, Alex Herbert  wrote:
>> 
>> 
>> 
>>> On 2 Jan 2020, at 16:53, Rob Tompkins  wrote:
>>> 
>>> +0 (could be convinced of +1)
>>> 
>>> RAT:
>>> 
>>> *
>>> Summary
>>> ---
>>> Generated at: 2020-01-02T10:45:36-05:00
>>> 
>>> Notes: 3
>>> Binaries: 4
>>> Archives: 1
>>> Standards: 287
>>> 
>>> Apache Licensed: 286
>>> Generated Documents: 0
>>> 
>>> JavaDocs are generated, thus a license header is optional.
>>> Generated files do not require license headers.
>>> 
>>> 1 Unknown Licenses
>>> 
>>> *
>>> 
>>> Files with unapproved licenses:
>>> 
>>> src/test/resources/empty.bin
>>> 
>>> *
>> 
>> Q. How did you manage to get this error?
>> 
>> apache-rat:check is in the default goal run by travis and 
>> 'src/test/resources/empty.bin’ has been in the pom.xml exclusions for a 
>> while.
>> 
>> I cannot reproduce this.
>> 
> 
> Curious. Not certain, but the build was with java 11. Let me start from 
> scratch in the morning and see if I can reproduce it. If I can indeed, then 
> I’ll send over my full mvn -version

I got this error when building from the unzipped -src.zip artifact. I’m also 
getting it when I run with the environment:

 mvn -version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3/libexec
Java version: 11.0.5, vendor: Amazon.com Inc., runtime: 
/Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.15.2", arch: "x86_64", family: “mac"

Not sure if that helps.

-Rob

> 
> -Rob
> 
>> Gary,
>> 
>> I have been on holiday so have not had time to do a full RC review. I may be 
>> able to do so in the next few days unless someone gets there first.
>> 
>> Alex
>> 
>> 
>> 
>> -
>> 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 Codec 1.14 based on RC1

[Claude Warren]

I am not a PMC member but, I'll report any way

+0 (non binding)

*FindBug* issues show: MurmurHash3 case fall through issues.  I believe
these are expected and can be fixed with an annotation.
Suggest release and fix in next update

*CPD* issues shows private static long getLittleEndianLong(final byte[]
data, final int index) in both Murmur2 and Murmur3.  This might actually
make a reasonable method in an "interpret buffer as number class".




Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T20:00:29+01:00)
Maven home: /home/claude/bin/apache-maven-3.6.1
Java version: 11.0.5, vendor: Private Build, runtime:
/usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_IE, platform encoding: UTF-8
OS name: "linux", version: "5.0.0-37-generic", arch: "amd64", family: "unix"

Linux zoltan-the-great 5.0.0-37-generic #40~18.04.1-Ubuntu SMP Thu Nov 14
12:06:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux


Claude


On Fri, Jan 3, 2020 at 4:20 AM Bruno P. Kinoshita
 wrote:

>[X] +1 Release these artifacts
>
>
> Build from tag passed with `mvn clean install site` on
>
>
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-18T06:33:14+12:00)
> Maven home: /opt/apache-maven-3.5.4
> Java version: 1.8.0_232, vendor: Private Build, runtime:
> /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_NZ, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-72-generic", arch: "amd64", family:
> "unix"
>
> Build with same command as above passed fine too with JDK 13, using the
> ZIP sources from the dist area.
>
>
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-18T06:33:14+12:00)
> Maven home: /opt/apache-maven-3.5.4
> Java version: 13, vendor: Oracle Corporation, runtime:
> /home/kinow/Development/java/jdk-13
> Default locale: en_NZ, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-72-generic", arch: "amd64", family:
> "unix"
>
> Had a look at files in the dist area and fond no issues. Site reports look
> good.
>
>
>
> Checked signatures and found no issues too.
>
>
> ThanksBruno
>
>
>
> On Tuesday, 31 December 2019, 2:00:12 pm NZDT, Gary Gregory <
> ggreg...@apache.org> wrote:
>
>  We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Codec 1.13 was released, so I would like to release
> Apache Commons Codec 1.14.
>
> Apache Commons Codec 1.14 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1 (svn
> revision 37409)
>
> The Git tag commons-codec-1.14-RC1 commit for this RC is
> af7b94750e2178b8437d9812b28e36ac87a455f2 which you can browse here:
>
>
> https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=af7b94750e2178b8437d9812b28e36ac87a455f2
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-codec.git
> --branch 
> commons-codec-1.14-RC1 commons-codec-1.14-RC1
>
> Maven artifacts are here:
>
>
> https://repository.apache.org/content/repositories/orgapachecommons-1483/commons-codec/commons-codec/1.14/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Mon Dec 30 19:44:19 EST 2019
>
> commons-codec-1.14-bin.tar.gz=bb21a15d0415513050d7738914b66bfe1f4612d7b44805ba208ec6d4fd923af244c98e828986cd4aa6cdcf9c78e23de981b5a34ac1abf805691a55f5be8cc0cf
>
> commons-codec-1.14-bin.zip=1119a418683ee9b599148b90056055fa93062e839ef426004c756c8054548cc1a80479f3b77a5a60c292e05ae67ae8699d46ae4ec25bad0070e17eb0e9e69756
>
> commons-codec-1.14-javadoc.jar=53dda4afcd159debd68aa8b3fdb22c6de02903e725d82203db2c8692da86091a4435664eb72df12a69e65f461712435ece81da9f0658587b2f6df3991d5a048a
>
> commons-codec-1.14-sources.jar=a0791dacf27154fa9453e16856d5b911b568eaada52a02535bb6170bdd13e97da32051d5359aa92ad0e69948450ff6f463aedc9a04f5f9ff4d5704e31e51a6b9
>
> commons-codec-1.14-src.tar.gz=1a98dc017d3213d8a89d11524683d45e9616fc6da8b4723cd1cfae23d73fefafeccc1c0f2994d1c4c52d79e1b825e4e09e601071572e2eb229105b3b4fd4a49b
>
> commons-codec-1.14-src.zip=0a7ebe348c9b12ee360e137c5bee833df4f7cfb259435ce6bda24073e8e1d3b76a202d4fd451efe29ddebcbcc31b3f7a287c7530d23bdc672129280d5c12d90e
>
> commons-codec-1.14-test-sources.jar=02c4fba74f028749abbf4bc44b328ed40fae3f60f53998dcaa2699284d337180b934ca93344271739f4e4df44643e87f7ce12dee35b252fa60f8f32ae60df460
>
> commons-codec-1.14-tests.jar=18dd09a0bd91040d857d84b0be39a482e884c701bcbbb5bbba990c80cf02d0270158bdbce8fa1b4473eeeb86d03ce1c4a3232d280f8b1356ee5c9f64d8a685a8
>
> I have tested this with:
>
> mvn -V -Duser.name=%my_apache_id%
> -Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease
> -Pjacoco -Pjapicmp -Ptest-deploy clean package site deploy
>
> using:
>
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\Java\apache-maven-3.6.3\bin\..
> Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_231\jre
> Default