Re: [DISCUSS] new component for timing?

On 2 March 2018 at 13:31, Oliver Heger wrote: > > One other suggestion: It was stated in the past that the concurrent > classes are also a bit out of scope for [lang], especially the circuit > breaker implementations. Would it make sense to move those into a new >

Re: [DISCUSS] new component for timing?

We could perhaps move some classes from the concurrent package too I think. Like the circuit breakers. That'd solve our current issue with java.desktop dependency and java9 Sent from Yahoo Mail on Android On Sat, 3 Mar 2018 at 3:45, Gary Gregory wrote: On Fri,

Re: [DISCUSS] new component for timing?

Am 02.03.2018 um 15:45 schrieb Gary Gregory: > On Fri, Mar 2, 2018 at 7:31 AM, Otto Fowler wrote: > >> I don’t understand the options that we are discussing here. Can we >> clarify? >> >> * create a new component from sirota, bringing it into commons ( resurrect >>

Re: [email] Update from Java 6 to 7

+1, otherwise we would have to revert https://github.com/apache/commons-email/commit/2239326be5c2791a23eea07eaed3d81f2e7000cf Am 02.03.2018 um 17:45 schrieb Gary Gregory: I propose we update Commons Email from Java 6 to Java 7. Gary

[email] Update from Java 6 to 7

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

Re: [VOTE][LAZY] Release Commons Release Plugin 1.1 based on RC4

+1 >From the src zip: ASC, Md5, SHA1 OK. Running 'mvn clean verify package site' builds OK using: Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T01:58:13-06:00) Maven home: C:\Java\apache-maven-3.5.2\bin\.. Java version: 1.8.0_162, vendor: Oracle Corporation Java home:

Re: [DISCUSS] new component for timing?

On Fri, Mar 2, 2018 at 7:31 AM, Otto Fowler wrote: > I don’t understand the options that we are discussing here. Can we > clarify? > > * create a new component from sirota, bringing it into commons ( resurrect > commons-monitoring ) and put StackWatch there? >

Re: [DISCUSS] new component for timing?

2018-03-02 15:31 GMT+01:00 Otto Fowler : > I don’t understand the options that we are discussing here. Can we > clarify? > > * create a new component from sirota, bringing it into commons ( resurrect > commons-monitoring ) and put StackWatch there? > I would more push

Re: [DISCUSS] new component for timing?

I don’t understand the options that we are discussing here. Can we clarify? * create a new component from sirota, bringing it into commons ( resurrect commons-monitoring ) and put StackWatch there? On March 2, 2018 at 08:49:03, Romain Manni-Bucau (rmannibu...@gmail.com) wrote: This i right

Re: [all] Is it ok to delete tags not voted upon?

In the past we've had the opposite issue: tags being deleted for canceled VOTEs. So for me, deleting tags that serve no purpose are a good thing. Gary On Fri, Mar 2, 2018 at 6:52 AM, Rob Tompkins wrote: > Hello all, > > I want to gage folks thoughts on this matter. If we

[all] Is it ok to delete tags not voted upon?

Hello all, I want to gage folks thoughts on this matter. If we are rolling a release candidate and find an issue after the tag has been committed, but before the vote has been emailed out, what should occur? My impression is to not delete anything pushed, but as Gary pointed out, this is

Re: [DISCUSS] new component for timing?

This i right but it started as just a few utilities and interception modules, then it grows as any performance related project. We also have skywalking which is quite big but can host all that utility part @asf. Romain Manni-Bucau @rmannibucau | Blog

Re: [VOTE][LAZY] Release Commons Release Plugin 1.1 based on RC4

That’s fair. My thought there was thinking not deleting tags pushed to git even if a mistake was found before the vote. I’d be happy to go back and delete them. I’ll run a separate thread with that discussion. -Rob > On Mar 2, 2018, at 8:44 AM, Gary Gregory wrote: >

Re: [DISCUSS] new component for timing?

My understanding is that sirona was/is a complete system, as opposed to a collection of utilities. If StackWatch is too big for LANG it seems too small for sirona. Along with sirona being retired etc. On February 28, 2018 at 15:06:52, Romain Manni-Bucau (rmannibu...@gmail.com) wrote: Le 28

Re: [VOTE][LAZY] Release Commons Release Plugin 1.1 based on RC4

FWIW, I think it is confusing to have tags for RCs in git for code we did not VOTE on. Gary On Fri, Mar 2, 2018 at 6:03 AM, Rob Tompkins wrote: > Hello all, > > This is a [VOTE][LAZY] for releasing Apache Commons Release Plugin 1.1 > (from RC4). > > Tag name: >

[VOTE][LAZY] Release Commons Release Plugin 1.1 based on RC4

Hello all, This is a [VOTE][LAZY] for releasing Apache Commons Release Plugin 1.1 (from RC4). Tag name: commons-release-plugin-1.1-RC4 (signature can be checked from git using 'git tag -v') Tag URL:

[CANCEL][VOTE][LAZY] Release Commons Release Plugin 1.1 based on RC2

Due to the -1 I am cancelling this vote, and am rebuilding the release candidate now. > On Feb 28, 2018, at 2:13 PM, Rob Tompkins wrote: > > Hello all, > > This is a [LAZY][VOTE] for releasing Apache Commons Release Plugin 1.1 (from > RC2). > > Tag name: >

JDK 10: Release Candidate & JDK 11 Early Access builds available

     Hi Benedikt, *JDK 10 build 45 is our JDK 10 Release Candidate and now available at http://jdk.java.net/10/* * Schedule, status & features o http://openjdk.java.net/projects/jdk/10/ * Release Notes o http://jdk.java.net/10/release-notes * Summary of changes in b45: o

AW: [email] Jenkins not building

I got the build running by injecting the required JAVA_1_6_HOME variable from $JDK_1_6_LATEST__HOME. I had to restrict the job on label "ubuntu" because in the meanwhile a Win2003 server without any Maven installed tried to do the job - without success ;-)

AW: [email] Jenkins not building

It seems that the job is failing, because the required environment variable JAVA_1_6_HOME is not set. (required by the 1.6-profile, defined in commons-parent). All available variables: https://builds.apache.org/job/commons-email/49/console Jan > -Ursprüngliche Nachricht- > Von: Jan