Re: [VOTE] Release Apache Commons Lang 3.9 based on RC1

> On Apr 9, 2019, at 9:15 PM, Gary Gregory wrote: > > +0... see Java 12 testing below. That +0 is almost worth cancelling for in my opinion. I’ll wait until tomorrow to see if anyone else wants to have an opinion here, and then I’ll have another go at it. -Rob > > Nit in the release note

Re: [VOTE] Release Apache Commons Lang 3.9 based on RC1

+0... see Java 12 testing below. Nit in the release notes: Replace "Java 8.0" with Java 8". >From the git tag, ran 'mvn -V clean package' OK for: Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T14:41:47-04:00) Maven home: C:\Java\apache-maven-3.6.0\bin\.. Java version: 1

Re: [VOTE] Release Apache Commons Lang 3.9 based on RC1

I also see that we are using an old version of jacoco and surefire, that probably matters... Gary On Tue, Apr 9, 2019 at 9:15 PM Gary Gregory wrote: > +0... see Java 12 testing below. > > Nit in the release notes: Replace "Java 8.0" with Java 8". > > From the git tag, ran 'mvn -V clean package'

[VOTE] Release Apache Commons Lang 3.9 based on RC1

We have fixed quite a few bugs and added some significant enhancements since Apache Commons Lang 3.8.1 was released, so I would like to release Apache Commons Lang 3.9. Apache Commons Lang 3.9 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/lang/3.9-RC1 (svn

Re: [rng] Split and Jump functions

On 09/04/2019 17:36, Gilles Sadowski wrote: Hello. Le mar. 9 avr. 2019 à 16:42, Alex Herbert a écrit : Hi Gilles, Lots of sensible discussion here. I'll just put all replies at the end. On 09/04/2019 13:28, Gilles Sadowski wrote: Hello. Hi Gilles, You ask some good questions which I ma

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 18:14, Rob Tompkins wrote: > > > > > On Apr 9, 2019, at 1:11 PM, sebb wrote: > > > > On Tue, 9 Apr 2019 at 17:06, Rob Tompkins > > wrote: > >> > >> > >> > >>> On Apr 9, 2019, at 11:57 AM, sebb wrote: > >>> > >>> On Tue, 9 Apr 2019 at 16:53, Joche

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

> On Apr 9, 2019, at 1:11 PM, sebb wrote: > > On Tue, 9 Apr 2019 at 17:06, Rob Tompkins > wrote: >> >> >> >>> On Apr 9, 2019, at 11:57 AM, sebb wrote: >>> >>> On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann >>> wrote: On Tue, Apr 9, 2019 at 3:51 PM seb

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 17:06, Rob Tompkins wrote: > > > > > On Apr 9, 2019, at 11:57 AM, sebb wrote: > > > > On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann > > wrote: > >> > >> On Tue, Apr 9, 2019 at 3:51 PM sebb wrote: > >> > >>> We already have a process for ensuring that Maven coords and packa

Re: [rng] Split and Jump functions

Hello. Le mar. 9 avr. 2019 à 16:42, Alex Herbert a écrit : > > Hi Gilles, > > Lots of sensible discussion here. I'll just put all replies at the end. > > On 09/04/2019 13:28, Gilles Sadowski wrote: > > Hello. > > > >> Hi Gilles, > >> > >> You ask some good questions which I may have been vague ab

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

> On Apr 9, 2019, at 11:57 AM, sebb wrote: > > On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann > wrote: >> >> On Tue, Apr 9, 2019 at 3:51 PM sebb wrote: >> >>> We already have a process for ensuring that Maven coords and package >>> names are changed when API breaks. >>> Do we really want to

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann wrote: > > On Tue, Apr 9, 2019 at 3:51 PM sebb wrote: > > > We already have a process for ensuring that Maven coords and package > > names are changed when API breaks. > > Do we really want to have yet another name that has to be maintained? > > What's

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 3:51 PM sebb wrote: > We already have a process for ensuring that Maven coords and package > names are changed when API breaks. > Do we really want to have yet another name that has to be maintained? What's the alternative? > Being able to define the module name independ

Re: [rng] Split and Jump functions

Hi Gilles, Lots of sensible discussion here. I'll just put all replies at the end. On 09/04/2019 13:28, Gilles Sadowski wrote: Hello. Hi Gilles, You ask some good questions which I may have been vague about due to familiarity with the possibilities. I hope to clarify a bit below. On 08/04/2

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 13:54, Jochen Wiedmann wrote: > > On Tue, Apr 9, 2019 at 2:43 PM sebb wrote: > > > Unless I am misunderstanding this, the property value won't be checked > > to see if i is changed when an incompatible versioni s released. > > True, but that applies in either case, as soon a

Re: [lang] 3.9, switch from cobertura to jacoco?

Bah, why not. Gary On Tue, Apr 9, 2019 at 9:24 AM Rob Tompkins wrote: > We want a jira for this? > > -Rob > > > On Apr 9, 2019, at 9:14 AM, Gary Gregory wrote: > > > > +1 > > > > Gary > > > > On Tue, Apr 9, 2019 at 8:39 AM Rob Tompkins wrote: > > > >> Thoughts on doing this switch? I’m heavil

Re: [VOTE] Release Apache Commons Pool 2.6.2 based on RC1

May I get more reviews please? Thank you, Gary On Mon, Apr 8, 2019 at 10:15 AM Gary Gregory wrote: > Looking for VOTEs... > > Gary > > On Sat, Apr 6, 2019 at 12:24 PM Gary Gregory > wrote: > >> Hi Sebb, >> >> Thank you for your review. Some comments below. >> >> On Sat, Apr 6, 2019 at 5:00 AM

Re: [lang] 3.9, switch from cobertura to jacoco?

We want a jira for this? -Rob > On Apr 9, 2019, at 9:14 AM, Gary Gregory wrote: > > +1 > > Gary > > On Tue, Apr 9, 2019 at 8:39 AM Rob Tompkins wrote: > >> Thoughts on doing this switch? I’m heavily leaning towards it because I >> can’t get code coverage to work on java 11 with the current

Re: [lang] 3.9, switch from cobertura to jacoco?

+1 Gary On Tue, Apr 9, 2019 at 8:39 AM Rob Tompkins wrote: > Thoughts on doing this switch? I’m heavily leaning towards it because I > can’t get code coverage to work on java 11 with the current build. > > -Rob > - > To unsubsc

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 2:43 PM sebb wrote: > Unless I am misunderstanding this, the property value won't be checked > to see if i is changed when an incompatible versioni s released. True, but that applies in either case, as soon as we have module names, doesn't it? So, I'd like to keep this out

Re: [lang] 3.9, switch from cobertura to jacoco?

On Tue, 9 Apr 2019 at 13:39, Rob Tompkins wrote: > > Thoughts on doing this switch? I’m heavily leaning towards it because I can’t > get code coverage to work on java 11 with the current build. +0 It's trivial to switch back isn't it? > -Rob > --

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

Le mar. 9 avr. 2019 à 14:11, Rob Tompkins a écrit : > > > > > On Apr 9, 2019, at 7:21 AM, Gilles Sadowski wrote: > > > > Le mar. 9 avr. 2019 à 13:03, sebb > > a écrit : > >> > >> On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski wrote: > >>> > [...] > > > > $ gi

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 12:43 PM Gilles Sadowski wrote: > ${commons.automatic.module.name} Fine with me. > Then the release plugin could be enhanced (?) so that it would check > whether the variable has been defined for each JAR to be created (and > fail the build otherwise). As already written

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 13:32, Jochen Wiedmann wrote: > > On Tue, Apr 9, 2019 at 10:48 AM John Patrick wrote: > > > > As commons-lang3 has the module name org.apache.commons.lang3, not > > commons-lang3 which is the artifactId, because "-" is invalid in a > > real module name and they realised this

[lang] 3.9, switch from cobertura to jacoco?

Thoughts on doing this switch? I’m heavily leaning towards it because I can’t get code coverage to work on java 11 with the current build. -Rob - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands,

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 2:37 PM Gary Gregory wrote: > Can't we do this in a more lightweight manner in Checkstyle or in our build > Maven plugin? I'll leave the former idea to you, and the latter to Rob. Myself, I don't know in both cases. But I am open. Jochen -

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 1:22 PM Gilles Sadowski wrote: > From > https://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html > ---CUT--- > Module names must be valid Java identifiers! E.g. no Java keywords, no > dashes, no... > ---CUT--- Wasn't aware of that, thanks for the hint. Jochen

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 8:32 AM Jochen Wiedmann wrote: > On Tue, Apr 9, 2019 at 10:48 AM John Patrick > wrote: > > > > As commons-lang3 has the module name org.apache.commons.lang3, not > > commons-lang3 which is the artifactId, because "-" is invalid in a > > real module name and they realised t

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 10:48 AM John Patrick wrote: > As commons-lang3 has the module name org.apache.commons.lang3, not > commons-lang3 which is the artifactId, because "-" is invalid in a > real module name and they realised this when starting to support jpms. Commons-lang, and others, can fi

Re: [rng] Split and Jump functions

Hello. > > Hi Gilles, > > You ask some good questions which I may have been vague about due to > familiarity with the possibilities. I hope to clarify a bit below. > > On 08/04/2019 16:05, Gilles Sadowski wrote: > > Hi Alex. > > > > Le lun. 8 avr. 2019 à 14:36, Alex Herbert a > > écrit : > >> Th

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 9:54 AM sebb wrote: > > I have studied EMAIL-186. My impression is, that all commons jar files > > should provide a fixed module name, rather than trusting in the choice > > of the JDK. Thus, it seems best to handle this in parent. So, here's > > my proposal for a change. P

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

> On Apr 9, 2019, at 7:21 AM, Gilles Sadowski wrote: > > Le mar. 9 avr. 2019 à 13:03, sebb > a écrit : >> >> On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski wrote: >>> [...] > > $ git diff pom.xml > diff --git a/pom.xml b/pom.xml > index 2612dd6..

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

Le mar. 9 avr. 2019 à 13:03, sebb a écrit : > > On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski wrote: > > > > > [...] > > > > > > > > $ git diff pom.xml > > > > diff --git a/pom.xml b/pom.xml > > > > index 2612dd6..54a88e4 100644 > > > > --- a/pom.xml > > > > +++ b/pom.xml > > > > @@ -570,6 +570,7

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski wrote: > > > [...] > > > > > > $ git diff pom.xml > > > diff --git a/pom.xml b/pom.xml > > > index 2612dd6..54a88e4 100644 > > > --- a/pom.xml > > > +++ b/pom.xml > > > @@ -570,6 +570,7 @@ > > > > > > ${implementation.build} > > >

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

> [...] > > > > $ git diff pom.xml > > diff --git a/pom.xml b/pom.xml > > index 2612dd6..54a88e4 100644 > > --- a/pom.xml > > +++ b/pom.xml > > @@ -570,6 +570,7 @@ > > > > ${implementation.build} > > > > ${maven.compiler.source} > > > > ${maven.compil

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 08:54, sebb wrote: > > On Tue, 9 Apr 2019 at 07:59, Jochen Wiedmann > wrote: > > > > Hi, > > > > I have studied EMAIL-186. My impression is, that all commons jar files > > should provide a fixed module name, rather than trusting in the choice > > of the JDK. Thus, it seems

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 07:59, Jochen Wiedmann wrote: > > Hi, > > I have studied EMAIL-186. My impression is, that all commons jar files > should provide a fixed module name, rather than trusting in the choice > of the JDK. Thus, it seems best to handle this in parent. So, here's > my proposal for a