RE: [crypto] On Java 6, really?

Thank all for the comments. I will file a jira to update CRYPTO to JDK 1.7. Regards Dapeng -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Wednesday, June 15, 2016 9:35 PM To: Commons Developers List Subject: Re: [crypto] On Java 6, really? On 15 June 2016 at 13:48, James

Build failed in Jenkins: Commons-CRYPTO-JDK1.6 » Apache Commons Crypto #48

See Changes: [sdp] CRYPTO-69: Activate Travis CI [sdp] CRYPTO-64: Remove code uses sun classes [sdp] CRYPTO-66: Fix compiling warning -- Established TCP

Build failed in Jenkins: Commons-CRYPTO-JDK1.6 #48

See Changes: [sdp] CRYPTO-69: Activate Travis CI [sdp] CRYPTO-64: Remove code uses sun classes [sdp] CRYPTO-66: Fix compiling warning -- Started by an SCM change [EnvInject] - Loading node

Jenkins build is back to normal : Commons-CRYPTO-JDK1.8 #27

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

Build failed in Jenkins: commons-bcel #11

See Changes: [dbrosius] add missing isVarArgs to AccessFlags -- [...truncated 121 lines...] Running org.apache.bcel.CounterVisitorTestCase Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time

Jenkins build is back to normal : Commons-CRYPTO-JDK1.7 #55

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

Re: [lang] replace clirr with japicmp

+1 Am 14.06.2016 um 07:29 schrieb Charles Honton: Now that lang is compiled with java6, clirr is broken. Do we want to update to a more modern report like japicmp ? The pom change is something like com.github.siom79.japicmp japicmp-maven-plugin

Re: Build failed in Jenkins: Commons-Compress-Windows #41

This starts to get annoying... Apache Jenkins Server schrieb am Mi., 15. Juni 2016 um 20:25: > See > > Changes: > > [sebb] Note re finalizer guarantee > > -- >

Build failed in Jenkins: Commons-Compress-Windows #41

See Changes: [sebb] Note re finalizer guarantee -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on windows2 (Windows) in workspace

Re: [ALL] Volunteers for a Math IPMC?

On Wed, Jun 15, 2016 at 10:21 AM, John D. Ament wrote: > Yep absolutely. I don't think the incubator has ever rejected a project? > We have discouraged some submissions. But I have never seen a formal submission be denied.

Re: [ALL] Volunteers for a Math IPMC?

On Wed, Jun 15, 2016 at 1:17 PM Ted Dunning wrote: > Jochen, > > The need to build the community (nearly) from scratch is definitely NOT a > reason for rejection. It is simply a risk factor that must be mitigated to > succeed in incubation. > Yep absolutely. I don't

Re: [ALL] Volunteers for a Math IPMC?

Jochen, The need to build the community (nearly) from scratch is definitely NOT a reason for rejection. It is simply a risk factor that must be mitigated to succeed in incubation. On Tue, Jun 14, 2016 at 10:51 PM, Jochen Wiedmann wrote: > On Tue, Jun 14, 2016 at

Re: [crypto] On Java 6, really?

On 15 June 2016 at 13:48, James Carman wrote: > If it's compiled at a higher target version, it's not a drop-in > replacement. They must upgrade their JRE. Only if their JRE is currently lower than the target version. So whether it will affect many users depends on

Jenkins build is back to stable : commons-fileupload #14

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

Jenkins build is back to stable : commons-fileupload » Apache Commons FileUpload #14

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

Re: [crypto] On Java 6, really?

If it's compiled at a higher target version, it's not a drop-in replacement. They must upgrade their JRE. One might argue that's actually *less* backward compatible. We've had this debate before. I don't really care which way we go, but let's make sure we stay true to the philosophy (if we want to

Jenkins build is still unstable: commons-fileupload » Apache Commons FileUpload #13

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

Jenkins build is still unstable: commons-fileupload » Apache Commons FileUpload #13

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

Re: [crypto] On Java 6, really?

On Tue, Jun 14, 2016, 10:57 Gary Gregory wrote: > On Jun 14, 2016 7:51 AM, "James Carman" > wrote: > > > > The trick is if we want to require a major version upgrade to bump JDK > > levels. That's why you'd want to bump it now if possible. > >

RE: [CRYPTO] Documenting the public API before it is too late...

Thanks sebb for the feedback. All the implementation classes shouldn't public. we are working on this. A JIRA (CRYPTO-71) was already created for the cipher implementation classes. We will continue. Regards, Xianda -Original Message- From: sebb [mailto:seb...@gmail.com] Sent:

Re: [CRYPTO] Documenting the public API before it is too late...

On Wed, Jun 15, 2016 at 11:20 AM, sebb wrote: > But please can we document the public API before it is too late? +1 Jochen -- The next time you hear: "Don't reinvent the wheel!"

RE: [crypto] Logging dependency

Thank all for your input! I will try to remove the log dependence. About the logging of native library failure, users of CRYPTO could get the information about whether native is enabled or native failure reason from org.apache.commons.crypto.utils.NativeCodeLoader#isNativeCodeLoaded() or

[CRYPTO] Documenting the public API before it is too late...

There does not currently seem to be any indication of which classes are part of the public API and which are only public or protected because of the restrictions of the Java permission scheme. Since there has so far been no release, this is the ideal time to document which APIs are intended to be

Re: Jenkins build is unstable: commons-fileupload » Apache Commons FileUpload #12

The last failure was due to errors in the test suite. Should be fixed. Sorry, Jochen On Wed, Jun 15, 2016 at 1:51 AM, Apache Jenkins Server wrote: > See > > -- The next

Re: [lang] replace clirr with japicmp

On Wed, Jun 15, 2016 at 6:45 AM, Charles Honton wrote: > According to clirr-maven-plugin pom, it depends on > net.sf.clirr:chirr-core:0.6 (released on 11-Feb-2006) > org.apache.bcel:bel:5.2 (release on 13-Jun-2006) > net.sf.clirr:chirr-core:0.6 had an excluded dependency on