Re: [crypto] Camel case for names

Sun, Dapeng schrieb am Do., 30. Juni 2016 um 07:32 Uhr: > +1 for keeping them consistent. > > I prefer "OpenSslCipher" > +1 for this as well. I don't like upper case abbreviations in class names. Benedikt > > Regards > Dapeng > > -Original Message- > From: Gary Gregory [mailto:garydgr

RE: [crypto] Camel case for names

+1 for keeping them consistent. I prefer "OpenSslCipher" Regards Dapeng -Original Message- From: Gary Gregory [mailto:garydgreg...@gmail.com] Sent: Thursday, June 30, 2016 9:35 AM To: Commons Developers List Subject: Re: [crypto] Camel case for names On Wed, Jun 29, 2016 at 5:33 PM, se

Re: [crypto] JNA and unit tests

On Wed, Jun 29, 2016 at 10:06 PM, Benedikt Ritter wrote: > JNA should ne removed again in order to push out an initial release! We're > again in the "lets make this perfect" mode, delaying the release with stuff > that has been discussed to be targeted for 1.x > The update to Java 7 is another ex

Re: [crypto] JNA and unit tests

JNA should ne removed again in order to push out an initial release! We're again in the "lets make this perfect" mode, delaying the release with stuff that has been discussed to be targeted for 1.x The update to Java 7 is another example for this. Benedikt sebb schrieb am Do., 30. Juni 2016 um 0

Re: [crypto] Camel case for names

On Wed, Jun 29, 2016 at 5:33 PM, sebb wrote: > The product is called OpenSSL, so perhaps it should be OpenSSLcipher > Even worse from my POV due to the lower case "c" in cipher. At work, we do camel case even for acronyms to avoid W3CXMLSAXThingy and get W3cXmlSaxThingy for example. I vote for

Re: [crypto] Camel case for names

The product is called OpenSSL, so perhaps it should be OpenSSLcipher On 30 June 2016 at 01:17, Gary Gregory wrote: > It seems to me that OpensslCipher should be called OpenSslCipher > > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Ed

Re: [2/2] commons-crypto git commit: try-with-resources.

I disagree with the -1s, but hey, that's just me -1. Reverted. G On Wed, Jun 29, 2016 at 5:19 PM, sebb wrote: > On 30 June 2016 at 01:08, wrote: > > try-with-resources. > > > > Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo > > Commit: > http://git-wip-us.apache.org/repos

Re: [1/2] commons-crypto git commit: try-with-resources.

On 30 June 2016 at 01:08, wrote: > Repository: commons-crypto > Updated Branches: > refs/heads/master bd9dfcd71 -> b11f6ffae > > > try-with-resources. > > Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo > Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/9

Re: [2/2] commons-crypto git commit: try-with-resources.

On 30 June 2016 at 01:08, wrote: > try-with-resources. > > Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo > Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/b11f6ffa > Tree: http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/b11f6ffa > Diff: http:/

[crypto] Camel case for names

It seems to me that OpensslCipher should be called OpenSslCipher Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action

Re: [crypto] JNA and unit tests

On 30 June 2016 at 01:06, Gary Gregory wrote: > On Wed, Jun 29, 2016 at 5:06 PM, Gary Gregory > wrote: > >> Now that we have the JNA backstop, some tests fail on Windows. It would be >> nice to be able to run ALL the tests with and without JNA. >> > > For example: > > org.junit.ComparisonFailure:

Re: [crypto] JNA and unit tests

On Wed, Jun 29, 2016 at 5:06 PM, Gary Gregory wrote: > Now that we have the JNA backstop, some tests fail on Windows. It would be > nice to be able to run ALL the tests with and without JNA. > For example: org.junit.ComparisonFailure: expected:<...mmons.crypto.cipher.[Openssl]Cipher> but was:<.

[crypto] JNA and unit tests

Now that we have the JNA backstop, some tests fail on Windows. It would be nice to be able to run ALL the tests with and without JNA. Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Sec

Re: [CRYPTO] inconsistent naming CryptoRandomFactory.getCryptoRandom : CryptoCipherFactory.getInstance

On Wed, Jun 29, 2016 at 4:53 PM, sebb wrote: > As the subject says; the two factories use a different naming convention. > > Would it be sensible to standardise on getInstance, given that the > class name says what the instance will be? > +1 Gary > > --

[CRYPTO] inconsistent naming CryptoRandomFactory.getCryptoRandom : CryptoCipherFactory.getInstance

As the subject says; the two factories use a different naming convention. Would it be sensible to standardise on getInstance, given that the class name says what the instance will be? - To unsubscribe, e-mail: dev-unsubscr...@com

Re: CLA should not be needed for Pull Requests

Great - fixes added to commons-build-plugin https://svn.apache.org/repos/asf/commons/proper/commons-build-plugin/trunk/src/main/resources/commons-xdoc-templates/ and applied on https://github.com/apache/commons-crypto/blob/master/README.md https://github.com/apache/commons-crypto/blob/master/C

Re: CLA should not be needed for Pull Requests

Maybe better: "Note that small patches & bug fixes do not require a CLA as clause 5 of the Apache License covers them." (also bug fix is not hyphenated). Gary On Wed, Jun 29, 2016 at 9:10 AM, Stian Soiland-Reyes wrote: > Suggested text: > > > Sign and submit the Apache Contributor License Agr

Re: CLA should not be needed for Pull Requests

Suggested text: > Sign and submit the Apache Contributor License Agreement if you haven't > already. Note that small patches & bug-fixes do not require a CLA as they are > covered by Apache License clause 5. On 29 June 2016 at 16:59, Stian Soiland-Reyes wrote: > https://github.com/apache/comm

CLA should not be needed for Pull Requests

https://github.com/apache/commons-collections/blob/trunk/CONTRIBUTING.md#submitting-changes says > Sign the Contributor License Agreement if you haven't already. > Push your changes to a topic branch in your fork of the repository. > Submit a pull request to the repository in the apache organizat

Re: commons-crypto git commit: Fallback no longer exists

+1 to make sure the Benchmark class is normally compiled (or at least during a -Prelease). JMH is licensed as ASF-incompatible GPL 2.0, but that's OK for a test dependency - particularly as a user can just remove it if they don't run the benchmark tests. On 29 June 2016 at 11:27, sebb AT AS

Re: commons-crypto git commit: Fallback no longer exists

This compile error was not picked up because the Benchmark class is only compiled if the -Pbenchmark profile is used. The class cannot currently be compiled in normal mode because it depends on JMH which is only included as a test dependency by the profile. I'm wondering whether the test dependen