Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Gary Gregory]

On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero  wrote:

> There is a one other compatibility issue, which can be seen in the attached
> code:
>
> import java.nio.charset.StandardCharsets;
>
> public class Weasel {
>
> private static final String US_ASCII = "US-ASCII";
> private static final String UTF_8 = "UTF-8";
> private static final String STANDARD_US_ASCII =
> StandardCharsets.US_ASCII.name();
> private static final String STANDARD_UTF_8 =
> StandardCharsets.UTF_8.name
> ();
>
> public static void main(String[] args) {
>
> switch (args[0]) {
> case US_ASCII:
> System.out.println("USA! USA!");
> break;
> case UTF_8:
> System.out.println("Emoji Lovin' Hippies!");
> break;
> default:
> System.out.println("Weirdo.");
> }
> }
> }
>
>
> This code compiles.
> However, if the case labels are changed to STANDARD_US_ASCII and
> STANDARD_UTF_8, the compilation will fail, because the  case labels are no
> longer constant expressions.
> In the actual code, this means that code compiled against an older version
> of the library would work against the new code (because the old strings had
> already been inlined), but could not be re-compiled.
>

Thank you for doing this research and POC :-)

But Ugh! :-( We shot ourselves in the foot here.

Benedikt, how do you feel about a fix and a new RC?

Gary


>
> I don't know why anyone would be doing this...
>
>  (CLIRR pre-dates string switches)
>
> Simon
>
> On Thu, Jun 8, 2017 at 5:10 PM, sebb  wrote:
>
> > On 8 June 2017 at 18:09, Gary Gregory  wrote:
> > > On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
> > >
> > >> On 8 June 2017 at 17:19, Gary Gregory  wrote:
> > >> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero 
> > wrote:
> > >> >
> > >> >> [A Note, not a vote :) ]
> > >> >>
> > >> >> 1. Clirr is generally considered obsolete, as it hadn't been worked
> > on
> > >> for
> > >> >> about ten years.   japicmp is a good replacement, especially for
> > report
> > >> >> generation, and is used in other commons projects.
> > >> >>
> > >> >
> > >> > IIRC, we've started using japicm here and there. Each component can
> > >> decide.
> > >> > But yes, Clirr looks pretty dead.
> > >> >
> > >> >
> > >> >> 2. Are the "changes" to the values in CharEncoding really
> > necessary[1]
> > >> (The
> > >> >> deprecation surely is). Technically this is a potentially breaking
> > >> binary
> > >> >> incompatible change, as constant strings and primitives are inlined
> > at
> > >> >> compile time. [2]
> > >> >> In this particular case, the results of load-time evaluation of the
> > new
> > >> >> initialization expressions  are identical to the old constants, so
> > it's
> > >> >> behaviourally compatible; however, since this is the case, and
> since
> > >> it's
> > >> >> all deprecated anyway, why not leave the old values in-place?
> > >> >>
> > >> >
> > >> > The changes are not "necessary" that for sure and we do get Clirr
> > >> warnings:
> > >> >
> > >> > Value of field ISO_8859_1 is no longer a compile-time constant
> > >> > Value of field US_ASCII is no longer a compile-time constant
> > >> > Value of field UTF_16 is no longer a compile-time constant
> > >> > Value of field UTF_16BE is no longer a compile-time constant
> > >> > Value of field UTF_16LE is no longer a compile-time constant
> > >> > Value of field UTF_8 is no longer a compile-time constant
> > >> >
> > >> > It's source compatible. What is the issue at runtime that could hurt
> > >> users?
> > >>
> > >> As the OP wrote, constants are inlined by the compiler.
> > >> So unless all code is recompiled, if it referenced the constant it may
> > >> have a stale value.
> > >> That is not binary compatible.
> > >>
> > >
> > > But in this case the actual values are the same are they not? So what
> is
> > > the difference? Would this only be a problem if we changed the string
> > > values?
> >
> > AFAIK the compiler only inlines compile-time constants.
> > So going forward, the values won't be inlined.
> > I assume the behaviour will be unaffected since the runtime value
> > should be the same as the constant.
> >
> > The release notes really ought to explain why the Clirr report items
> > aren't a problem.
> >
> > > Which we can't since these are defined in the JRE. And the JRE is
> > > unlikely to change those.
> > >
> > > Gary
> > >
> > >
> > >>
> > >> >
> > >> >> 3. JDK9 adds some extra parameters to the Deprecated annotation
> (most
> > >> >> notably  forRemoval=true, which is used to indicate that the
> > annotated
> > >> item
> > >> >> is really really deprecated.)   It's not needed in this case, but
> is
> > >> worth
> > >> >> thinking about  when jdk9 is eventually released (latest schedule
> > >> change :
> > >> >> from 7/27/2017 to 9/21/2017).
> > >> 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Simon Spero]

There is a one other compatibility issue, which can be seen in the attached
code:

import java.nio.charset.StandardCharsets;

public class Weasel {

private static final String US_ASCII = "US-ASCII";
private static final String UTF_8 = "UTF-8";
private static final String STANDARD_US_ASCII =
StandardCharsets.US_ASCII.name();
private static final String STANDARD_UTF_8 = StandardCharsets.UTF_8.name
();

public static void main(String[] args) {

switch (args[0]) {
case US_ASCII:
System.out.println("USA! USA!");
break;
case UTF_8:
System.out.println("Emoji Lovin' Hippies!");
break;
default:
System.out.println("Weirdo.");
}
}
}


This code compiles.
However, if the case labels are changed to STANDARD_US_ASCII and
STANDARD_UTF_8, the compilation will fail, because the  case labels are no
longer constant expressions.
In the actual code, this means that code compiled against an older version
of the library would work against the new code (because the old strings had
already been inlined), but could not be re-compiled.

I don't know why anyone would be doing this...

 (CLIRR pre-dates string switches)

Simon

On Thu, Jun 8, 2017 at 5:10 PM, sebb  wrote:

> On 8 June 2017 at 18:09, Gary Gregory  wrote:
> > On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
> >
> >> On 8 June 2017 at 17:19, Gary Gregory  wrote:
> >> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero 
> wrote:
> >> >
> >> >> [A Note, not a vote :) ]
> >> >>
> >> >> 1. Clirr is generally considered obsolete, as it hadn't been worked
> on
> >> for
> >> >> about ten years.   japicmp is a good replacement, especially for
> report
> >> >> generation, and is used in other commons projects.
> >> >>
> >> >
> >> > IIRC, we've started using japicm here and there. Each component can
> >> decide.
> >> > But yes, Clirr looks pretty dead.
> >> >
> >> >
> >> >> 2. Are the "changes" to the values in CharEncoding really
> necessary[1]
> >> (The
> >> >> deprecation surely is). Technically this is a potentially breaking
> >> binary
> >> >> incompatible change, as constant strings and primitives are inlined
> at
> >> >> compile time. [2]
> >> >> In this particular case, the results of load-time evaluation of the
> new
> >> >> initialization expressions  are identical to the old constants, so
> it's
> >> >> behaviourally compatible; however, since this is the case, and since
> >> it's
> >> >> all deprecated anyway, why not leave the old values in-place?
> >> >>
> >> >
> >> > The changes are not "necessary" that for sure and we do get Clirr
> >> warnings:
> >> >
> >> > Value of field ISO_8859_1 is no longer a compile-time constant
> >> > Value of field US_ASCII is no longer a compile-time constant
> >> > Value of field UTF_16 is no longer a compile-time constant
> >> > Value of field UTF_16BE is no longer a compile-time constant
> >> > Value of field UTF_16LE is no longer a compile-time constant
> >> > Value of field UTF_8 is no longer a compile-time constant
> >> >
> >> > It's source compatible. What is the issue at runtime that could hurt
> >> users?
> >>
> >> As the OP wrote, constants are inlined by the compiler.
> >> So unless all code is recompiled, if it referenced the constant it may
> >> have a stale value.
> >> That is not binary compatible.
> >>
> >
> > But in this case the actual values are the same are they not? So what is
> > the difference? Would this only be a problem if we changed the string
> > values?
>
> AFAIK the compiler only inlines compile-time constants.
> So going forward, the values won't be inlined.
> I assume the behaviour will be unaffected since the runtime value
> should be the same as the constant.
>
> The release notes really ought to explain why the Clirr report items
> aren't a problem.
>
> > Which we can't since these are defined in the JRE. And the JRE is
> > unlikely to change those.
> >
> > Gary
> >
> >
> >>
> >> >
> >> >> 3. JDK9 adds some extra parameters to the Deprecated annotation (most
> >> >> notably  forRemoval=true, which is used to indicate that the
> annotated
> >> item
> >> >> is really really deprecated.)   It's not needed in this case, but is
> >> worth
> >> >> thinking about  when jdk9 is eventually released (latest schedule
> >> change :
> >> >> from 7/27/2017 to 9/21/2017).
> >> >>
> >> >
> >> > I do not think we plan on making Java 9 a requirement for any current
> >> > project.
> >> >
> >> > Gary
> >> >
> >> >
> >> >>
> >> >> Simon
> >> >>
> >> >> [1]  https://github.com/apache/commons-lang/commit/7c19a1ff4c217
> >> >> f03c0be62baf1169d689f566825#diff-820a48456e11e85bf6cf5356c1aed4baR48
> >> >>
> >> >> [2] https://docs.oracle.com/javase/specs/jls/se8/html/jls-
> >> >> 13.html#jls-13.4.9
> >> >>
> >> >> On Jun 8, 2017 4:48 AM, "Benedikt Ritter" 
> 

Re: NUMBERS-40: Review exception usage in package "o.a.c.numbers.gamma"

[Tharaka De Silva]

Thank you for the response!

On Thu, Jun 8, 2017 at 5:13 AM, Gilles  wrote:

> Hi.
>
> On Wed, 7 Jun 2017 17:00:46 -0500, Tharaka De Silva wrote:
>
>> Hello everyone,
>>
>> I am new to the ASF community
>>
>
> Welcome.


Thank you!


>
>
> and decided to grab something easy to
>> attempt. I decided to take a shot at:
>> https://issues.apache.org/jira/browse/NUMBERS-40.
>>
>
> Easy to change is not always similar to easy to decide what
> changes to perform. ;-)
>
>
I did not think of it that way. It makes sense.


>
>> The rationale of implementing this design would be this:
>> GammaException is currently a subclass of IllegalArgumentException but the
>> reason for an argument to be invalid would be because it is arithmetically
>> impossible hence why it should be an ArithmeticException rather than a
>> IllegalArgumentException.
>>
>
> In quite a few cases, it is actually _not_ "arithmetically impossible",
> it is a limitation of the implementation.
>

I was looking at it and the one I saw was for negative log and I made my
assumptions from that.


>
> The JIRA report asks whether it is possible to use a single exception
> type (currently "GammaException") for all programming errors, given that
> the base class of all errors _cannot_ be "ArithmeticException" (as the
> above explains).
>
>
So you think that leaving it as a subclass of IllegalArgumentException
makes more sense?


> As an aside, in the unit tests, the use of the exception's base (JDK)
> class in the "expected" clause is intentional as the unit tests are
> mainly supposed to  check the public API (and "GammaException" is
> package-private).
> In "Commons Numbers", the idea would be to have a most simple exception
> handling (throwing only JDK exceptions) since it is expected (TBC) that
> all of them result from incorrect usage or bugs in the library.
>

Yeah, I didn't think of it this way. The unit tests probably should
probably be modified to assert for the JDK exceptions.


>
>
> Regards,
> Gilles
>
>
>> What do you guys think?
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Sincerely,

Tharaka De Silva

[GitHub] commons-cli pull request #10: [CLI-274] implement EXISTING_FILE_VALUE type h...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-cli/pull/10


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-cli pull request #3: [CLI-253] Prevent "Unrecognized option: --null"...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-cli/pull/3


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[sebb]

On 8 June 2017 at 18:09, Gary Gregory  wrote:
> On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
>
>> On 8 June 2017 at 17:19, Gary Gregory  wrote:
>> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero  wrote:
>> >
>> >> [A Note, not a vote :) ]
>> >>
>> >> 1. Clirr is generally considered obsolete, as it hadn't been worked on
>> for
>> >> about ten years.   japicmp is a good replacement, especially for report
>> >> generation, and is used in other commons projects.
>> >>
>> >
>> > IIRC, we've started using japicm here and there. Each component can
>> decide.
>> > But yes, Clirr looks pretty dead.
>> >
>> >
>> >> 2. Are the "changes" to the values in CharEncoding really necessary[1]
>> (The
>> >> deprecation surely is). Technically this is a potentially breaking
>> binary
>> >> incompatible change, as constant strings and primitives are inlined at
>> >> compile time. [2]
>> >> In this particular case, the results of load-time evaluation of the new
>> >> initialization expressions  are identical to the old constants, so it's
>> >> behaviourally compatible; however, since this is the case, and since
>> it's
>> >> all deprecated anyway, why not leave the old values in-place?
>> >>
>> >
>> > The changes are not "necessary" that for sure and we do get Clirr
>> warnings:
>> >
>> > Value of field ISO_8859_1 is no longer a compile-time constant
>> > Value of field US_ASCII is no longer a compile-time constant
>> > Value of field UTF_16 is no longer a compile-time constant
>> > Value of field UTF_16BE is no longer a compile-time constant
>> > Value of field UTF_16LE is no longer a compile-time constant
>> > Value of field UTF_8 is no longer a compile-time constant
>> >
>> > It's source compatible. What is the issue at runtime that could hurt
>> users?
>>
>> As the OP wrote, constants are inlined by the compiler.
>> So unless all code is recompiled, if it referenced the constant it may
>> have a stale value.
>> That is not binary compatible.
>>
>
> But in this case the actual values are the same are they not? So what is
> the difference? Would this only be a problem if we changed the string
> values?

AFAIK the compiler only inlines compile-time constants.
So going forward, the values won't be inlined.
I assume the behaviour will be unaffected since the runtime value
should be the same as the constant.

The release notes really ought to explain why the Clirr report items
aren't a problem.

> Which we can't since these are defined in the JRE. And the JRE is
> unlikely to change those.
>
> Gary
>
>
>>
>> >
>> >> 3. JDK9 adds some extra parameters to the Deprecated annotation (most
>> >> notably  forRemoval=true, which is used to indicate that the annotated
>> item
>> >> is really really deprecated.)   It's not needed in this case, but is
>> worth
>> >> thinking about  when jdk9 is eventually released (latest schedule
>> change :
>> >> from 7/27/2017 to 9/21/2017).
>> >>
>> >
>> > I do not think we plan on making Java 9 a requirement for any current
>> > project.
>> >
>> > Gary
>> >
>> >
>> >>
>> >> Simon
>> >>
>> >> [1]  https://github.com/apache/commons-lang/commit/7c19a1ff4c217
>> >> f03c0be62baf1169d689f566825#diff-820a48456e11e85bf6cf5356c1aed4baR48
>> >>
>> >> [2] https://docs.oracle.com/javase/specs/jls/se8/html/jls-
>> >> 13.html#jls-13.4.9
>> >>
>> >> On Jun 8, 2017 4:48 AM, "Benedikt Ritter"  wrote:
>> >>
>> >> > Hello,
>> >> >
>> >> > we have fixed quite a few bugs and added some nice new features since
>> >> > Commons Lang 3.5 was released, so I would like to release Commons Lang
>> >> 3.6
>> >> > based on RC3.
>> >> > The following issues have been fixed since RC2:
>> >> >
>> >> > - Site build now works from source distribution
>> >> > - IBM JDK test failures have been fixed
>> >> > - Automatic-Module-Name MANIFEST entry has been added for Java 9
>> >> > compatibility
>> >> >
>> >> > Commons Lang 3.6 R3 is available for review here:
>> >> >  https://dist.apache.org/repos/dist/dev/commons/lang (svn revision
>> >> 19928)
>> >> >
>> >> > The tag is here:
>> >> > https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=
>> >> > e454e79463ffbbd9114db43019dd211debbcc105
>> >> >
>> >> > Commit ID the tag points at:
>> >> >  360198dfb6a2d68f1702f616dfacee34ae0541bb
>> >> >
>> >> > Maven Artifacts:
>> >> >  https://repository.apache.org/content/repositories/
>> >> orgapachecommons-1250
>> >> >
>> >> > These are the Maven artifacts and their hashes:
>> >> >
>> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar
>> >> > (SHA1: c8adadb6c0b56c73f2cc2b4c77a09bfe34ec3a66)
>> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
>> sources.jar.asc
>> >> > (SHA1: 46347c179ca9246d146d653bdc7363bda6f17d44)
>> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom.asc
>> >> > (SHA1: 1309d4f3dd41a01ff9dd1f3c1a6eee10dad1ef77)
>> >> > 

Re: [LANG] Fix date related test failures on IBM JDKs (Was: Re: [CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC2)

[Amey Jadiye]

Hi Gary,

I have raised PR[1] for this please review, I have already tested on forked
repo [2], works like a charm, now each commit will be tested against.
- openjdk7
- oraclejdk7
- oraclejdk8
- ibmjdk8

 [1] https://github.com/apache/commons-text/pull/45
 [2] https://travis-ci.org/ameyjadiye/commons-text

any suggestion or improvement will be appreciated.

Regards,
Amey

On Fri, Jun 9, 2017 at 12:02 AM, Amey Jadiye  wrote:

> *Glad to setup this, I will submit PR soon.*
>
> *I'm taking commons-text as test mice, once it's successfully running we
> can replicate same setup to other components.*
>
> *Regards,*
>
> *Amey*
>
> On Thu, Jun 8, 2017 at 11:31 PM, Gary Gregory 
> wrote:
>
>> On Thu, Jun 8, 2017 at 8:55 AM, Amey Jadiye  wrote:
>>
>> > Hi All/Gary/Benedikt/Bruno,
>> >
>> > May be i'm late in this discussion, just had thought around ibmjdk8 that
>> > can we add ibm-jdk8 in our travis.yml file for checking builds against
>> it ?
>> > might be helpful to avoid problem we fixed with LANG-1337
>> >
>> > I was looking at the way we can do that because the fact that Travis
>> don't
>> > support ibm-jdk8, however proposal is raised [1] so hope we can get it
>> in
>> > future.   I also found the workaround till we get it here [2].
>> >
>>
>> Cool. Are you available to provide a PR?
>>
>> Gary
>>
>>
>> >
>> > [1] https://github.com/travis-ci/travis-ci/issues/2682
>> > [2] https://github.com/DanHeidinga/IBM-J9-DockerImage-For-TravisCI
>> >
>> > Regards,
>> > Amey
>> >
>> > On Tue, Jun 6, 2017, 5:15 PM Bruno P. Kinoshita
>> >  wrote:
>> > >
>> > > Actually, here it goes https://github.com/apache/comm
>> ons-lang/pull/269.
>> > >
>> > > If anyone else with the latest IBM JDK 8 could test and confirm it
>> works.
>> > Worked for me on IBM JDK 8, Oracle JDK 7, and Oracle JDK 8; Ubuntu 16.04
>> > LTS, Maven 3.3.9.
>> > >
>> > > Cheers
>> > > Bruno
>> > > 
>> > > From: Bruno P. Kinoshita 
>> > > To: Commons Developers List 
>> > > Sent: Tuesday, 6 June 2017 10:13 PM
>> > > Subject: Re: [LANG] Fix date related test failures on IBM JDKs (Was:
>> Re:
>> > [CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC2)
>> > >
>> > >
>> > >
>> > > I am downloading the latest IBM JDK in order to test other components
>> > too, and might have some spare time this week to fix it, as I'm
>> switching
>> > jobs next week. But  happy if anyone beats me to it and finds the bug
>> first
>> > :)
>> > >
>> > > CheersBruno
>> > >
>> > >
>> > >   From: Benedikt Ritter 
>> > >
>> > > To: Commons Developers List 
>> > >
>> > > Sent: Monday, 5 June 2017 10:54 PM
>> > >
>> > > Subject: [LANG] Fix date related test failures on IBM JDKs (Was: Re:
>> > [CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC2)
>> > >
>> > >
>> > >
>> > > Hi,
>> > >
>> > >
>> > > > Am 25.05.2017 um 13:16 schrieb sebb :
>> > >
>> > > >
>> > >
>> > > > On 25 May 2017 at 01:02, Gary Gregory > > > garydgreg...@gmail.com>> wrote:
>> > >
>> > > >> On Wed, May 24, 2017 at 4:46 PM, Gary Gregory <
>> garydgreg...@gmail.com
>> > >
>> > >
>> > > >> wrote:
>> > >
>> > > >>
>> > >
>> > > >>> On Wed, May 24, 2017 at 2:12 PM, Rob Tompkins > >
>> > wrote:
>> > >
>> > > >>>
>> > >
>> > > 
>> > >
>> > > > On May 24, 2017, at 2:49 AM, Gary Gregory <
>> garydgreg...@gmail.com>
>> > >
>> > >  wrote:
>> > >
>> > > >
>> > >
>> > > > When I build with the IBM JDK 8 that IBM includes with some
>> Eclipse
>> > >
>> > >  version
>> > >
>> > > > I have laying around, I indeed get:
>> > >
>> > > >
>> > >
>> > > > java (2)
>> > >
>> > > > org.apache.commons.lang3.time.FastDateParser_TimeZoneStrateg
>> yTest
>> > >
>> > > > testLang1219(org.apache.commons.lang3.time.FastDateParser_Ti
>> > >
>> > >  meZoneStrategyTest)
>> > >
>> > > > java.text.ParseException: Unparseable date: 26.10.2014 02:00:00
>> > MESZ
>> > >
>> > > 
>> > >
>> > > >>>
>> > >
>> > > >>> As I mentioned, the above test passes with the current IBM SDK 8:
>> > >
>> > > >>>
>> > >
>> > > >>> Java(TM) SE Runtime Environment (build
>> pwi3280sr4fp5-20170421_01(SR4
>> > FP5))
>> > >
>> > > >>> IBM J9 VM (build 2.8, JRE 1.8.0 Windows 10 x86-32 20170419_344392
>> > (JIT
>> > >
>> > > >>> enabled, AOT enabled)
>> > >
>> > > >>> J9VM - R28_20170419_1004_B344392
>> > >
>> > > >>> JIT  - tr.r14.java_20170419_344392
>> > >
>> > > >>> GC  - R28_20170419_1004_B344392
>> > >
>> > > >>> J9CL - 20170419_344392)
>> > >
>> > > >>> JCL - 20170420_01 based on Oracle jdk8u131-b11
>> > >
>> > > >>>
>> > >
>> > > >>> So IMO the only test we should look at is:
>> > >
>> > > >>>
>> > >
>> > >  org.apache.commons.lang3.builder.ToStringBuilderTest
>> > >
>> > >  

[GitHub] commons-text issue #45: Added IBM Jdk8 build support to travis-ci configurat...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/45
  

[![Coverage 
Status](https://coveralls.io/builds/11892865/badge)](https://coveralls.io/builds/11892865)

Coverage remained the same at 96.653% when pulling 
**90b5426b33476d091b19eb50de8d352a2295b8c7 on ameyjadiye:travis-ibmjdk8** into 
**5f498c0f4783d035bfeb77517731c948f8567b1e on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-text issue #45: Added IBM Jdk8 build support to travis-ci configurat...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/45
  

[![Coverage 
Status](https://coveralls.io/builds/11892865/badge)](https://coveralls.io/builds/11892865)

Coverage remained the same at 96.653% when pulling 
**90b5426b33476d091b19eb50de8d352a2295b8c7 on ameyjadiye:travis-ibmjdk8** into 
**5f498c0f4783d035bfeb77517731c948f8567b1e on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [ANNOUNCE] Apache Commons CLI moved to git

[Gary Gregory]

Good idea to announce! :-)

Gary

On Jun 8, 2017 11:19 AM, "Benedikt Ritter"  wrote:

> Hello,
>
> the Apache Commons CLI component has been moved to git. The new source
> repository location is:
>
>   https://git-wip-us.apache.org/repos/asf/commons-cli.git
>
> The old SVN source tree has been moved to an archive location at:
>
>   https://svn.apache.org/repos/asf/commons/_moved_to_git/cli
>
> Have fun!
> Benedikt
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

[GitHub] commons-text pull request #45: Added IBM Jdk8 build support to travis-ci con...

[ameyjadiye]

GitHub user ameyjadiye opened a pull request:

https://github.com/apache/commons-text/pull/45

Added IBM Jdk8 build support to travis-ci configuration



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ameyjadiye/commons-text travis-ibmjdk8

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-text/pull/45.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #45


commit 4774bb19f318ee15232f4d5f3cc08245eb9b9b3a
Author: Amey Jadiye 
Date:   2017-06-08T19:50:27Z

adding ibmjdk8 support to commons-text

commit 90b5426b33476d091b19eb50de8d352a2295b8c7
Author: Amey Jadiye 
Date:   2017-06-08T19:59:59Z

assume yes for all apt-get install




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [LANG] Fix date related test failures on IBM JDKs (Was: Re: [CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC2)

[Amey Jadiye]

*Glad to setup this, I will submit PR soon.*

*I'm taking commons-text as test mice, once it's successfully running we
can replicate same setup to other components.*

*Regards,*

*Amey*

On Thu, Jun 8, 2017 at 11:31 PM, Gary Gregory 
wrote:

> On Thu, Jun 8, 2017 at 8:55 AM, Amey Jadiye  wrote:
>
> > Hi All/Gary/Benedikt/Bruno,
> >
> > May be i'm late in this discussion, just had thought around ibmjdk8 that
> > can we add ibm-jdk8 in our travis.yml file for checking builds against
> it ?
> > might be helpful to avoid problem we fixed with LANG-1337
> >
> > I was looking at the way we can do that because the fact that Travis
> don't
> > support ibm-jdk8, however proposal is raised [1] so hope we can get it in
> > future.   I also found the workaround till we get it here [2].
> >
>
> Cool. Are you available to provide a PR?
>
> Gary
>
>
> >
> > [1] https://github.com/travis-ci/travis-ci/issues/2682
> > [2] https://github.com/DanHeidinga/IBM-J9-DockerImage-For-TravisCI
> >
> > Regards,
> > Amey
> >
> > On Tue, Jun 6, 2017, 5:15 PM Bruno P. Kinoshita
> >  wrote:
> > >
> > > Actually, here it goes https://github.com/apache/commons-lang/pull/269
> .
> > >
> > > If anyone else with the latest IBM JDK 8 could test and confirm it
> works.
> > Worked for me on IBM JDK 8, Oracle JDK 7, and Oracle JDK 8; Ubuntu 16.04
> > LTS, Maven 3.3.9.
> > >
> > > Cheers
> > > Bruno
> > > 
> > > From: Bruno P. Kinoshita 
> > > To: Commons Developers List 
> > > Sent: Tuesday, 6 June 2017 10:13 PM
> > > Subject: Re: [LANG] Fix date related test failures on IBM JDKs (Was:
> Re:
> > [CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC2)
> > >
> > >
> > >
> > > I am downloading the latest IBM JDK in order to test other components
> > too, and might have some spare time this week to fix it, as I'm switching
> > jobs next week. But  happy if anyone beats me to it and finds the bug
> first
> > :)
> > >
> > > CheersBruno
> > >
> > >
> > >   From: Benedikt Ritter 
> > >
> > > To: Commons Developers List 
> > >
> > > Sent: Monday, 5 June 2017 10:54 PM
> > >
> > > Subject: [LANG] Fix date related test failures on IBM JDKs (Was: Re:
> > [CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC2)
> > >
> > >
> > >
> > > Hi,
> > >
> > >
> > > > Am 25.05.2017 um 13:16 schrieb sebb :
> > >
> > > >
> > >
> > > > On 25 May 2017 at 01:02, Gary Gregory   > garydgreg...@gmail.com>> wrote:
> > >
> > > >> On Wed, May 24, 2017 at 4:46 PM, Gary Gregory <
> garydgreg...@gmail.com
> > >
> > >
> > > >> wrote:
> > >
> > > >>
> > >
> > > >>> On Wed, May 24, 2017 at 2:12 PM, Rob Tompkins 
> > wrote:
> > >
> > > >>>
> > >
> > > 
> > >
> > > > On May 24, 2017, at 2:49 AM, Gary Gregory <
> garydgreg...@gmail.com>
> > >
> > >  wrote:
> > >
> > > >
> > >
> > > > When I build with the IBM JDK 8 that IBM includes with some
> Eclipse
> > >
> > >  version
> > >
> > > > I have laying around, I indeed get:
> > >
> > > >
> > >
> > > > java (2)
> > >
> > > > org.apache.commons.lang3.time.FastDateParser_
> TimeZoneStrategyTest
> > >
> > > > testLang1219(org.apache.commons.lang3.time.FastDateParser_Ti
> > >
> > >  meZoneStrategyTest)
> > >
> > > > java.text.ParseException: Unparseable date: 26.10.2014 02:00:00
> > MESZ
> > >
> > > 
> > >
> > > >>>
> > >
> > > >>> As I mentioned, the above test passes with the current IBM SDK 8:
> > >
> > > >>>
> > >
> > > >>> Java(TM) SE Runtime Environment (build
> pwi3280sr4fp5-20170421_01(SR4
> > FP5))
> > >
> > > >>> IBM J9 VM (build 2.8, JRE 1.8.0 Windows 10 x86-32 20170419_344392
> > (JIT
> > >
> > > >>> enabled, AOT enabled)
> > >
> > > >>> J9VM - R28_20170419_1004_B344392
> > >
> > > >>> JIT  - tr.r14.java_20170419_344392
> > >
> > > >>> GC  - R28_20170419_1004_B344392
> > >
> > > >>> J9CL - 20170419_344392)
> > >
> > > >>> JCL - 20170420_01 based on Oracle jdk8u131-b11
> > >
> > > >>>
> > >
> > > >>> So IMO the only test we should look at is:
> > >
> > > >>>
> > >
> > >  org.apache.commons.lang3.builder.ToStringBuilderTest
> > >
> > >  testReflectionHierarchyArrayList(org.apache.commons.lang3.bu
> > >
> > > >>> ilder.ToStringBuilderTest)
> > >
> > >  org.junit.ComparisonFailure:
> > >
> > >  expected:<...700dfa[elementData={[,,,<
> > >
> > > >>> null>,,]},size=0,
> > modCount=0]>
> > >
> > >  but was:<...700dfa[elementData={[]},size=0,modCount=0]>
> > >
> > > >>>
> > >
> > > >>
> > >
> > > >> Looking at this a little more, I would say that IBM Java changed how
> > it
> > >
> > > >> implemented ArrayList between it's 1.6 and 1.8 releases. I only have
> > the
> > >
> > > >> current 1.8 IBM release. I cannot verify that this test makes sense
> on
> > IBM
> > >
> > > >> 

[ANNOUNCE] Apache Commons CLI moved to git

[Benedikt Ritter]

Hello,

the Apache Commons CLI component has been moved to git. The new source 
repository location is:

  https://git-wip-us.apache.org/repos/asf/commons-cli.git

The old SVN source tree has been moved to an archive location at:

  https://svn.apache.org/repos/asf/commons/_moved_to_git/cli

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

Re: [LANG] Fix date related test failures on IBM JDKs (Was: Re: [CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC2)

[Gary Gregory]

On Thu, Jun 8, 2017 at 8:55 AM, Amey Jadiye  wrote:

> Hi All/Gary/Benedikt/Bruno,
>
> May be i'm late in this discussion, just had thought around ibmjdk8 that
> can we add ibm-jdk8 in our travis.yml file for checking builds against it ?
> might be helpful to avoid problem we fixed with LANG-1337
>
> I was looking at the way we can do that because the fact that Travis don't
> support ibm-jdk8, however proposal is raised [1] so hope we can get it in
> future.   I also found the workaround till we get it here [2].
>

Cool. Are you available to provide a PR?

Gary


>
> [1] https://github.com/travis-ci/travis-ci/issues/2682
> [2] https://github.com/DanHeidinga/IBM-J9-DockerImage-For-TravisCI
>
> Regards,
> Amey
>
> On Tue, Jun 6, 2017, 5:15 PM Bruno P. Kinoshita
>  wrote:
> >
> > Actually, here it goes https://github.com/apache/commons-lang/pull/269.
> >
> > If anyone else with the latest IBM JDK 8 could test and confirm it works.
> Worked for me on IBM JDK 8, Oracle JDK 7, and Oracle JDK 8; Ubuntu 16.04
> LTS, Maven 3.3.9.
> >
> > Cheers
> > Bruno
> > 
> > From: Bruno P. Kinoshita 
> > To: Commons Developers List 
> > Sent: Tuesday, 6 June 2017 10:13 PM
> > Subject: Re: [LANG] Fix date related test failures on IBM JDKs (Was: Re:
> [CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC2)
> >
> >
> >
> > I am downloading the latest IBM JDK in order to test other components
> too, and might have some spare time this week to fix it, as I'm switching
> jobs next week. But  happy if anyone beats me to it and finds the bug first
> :)
> >
> > CheersBruno
> >
> >
> >   From: Benedikt Ritter 
> >
> > To: Commons Developers List 
> >
> > Sent: Monday, 5 June 2017 10:54 PM
> >
> > Subject: [LANG] Fix date related test failures on IBM JDKs (Was: Re:
> [CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC2)
> >
> >
> >
> > Hi,
> >
> >
> > > Am 25.05.2017 um 13:16 schrieb sebb :
> >
> > >
> >
> > > On 25 May 2017 at 01:02, Gary Gregory > wrote:
> >
> > >> On Wed, May 24, 2017 at 4:46 PM, Gary Gregory  >
> >
> > >> wrote:
> >
> > >>
> >
> > >>> On Wed, May 24, 2017 at 2:12 PM, Rob Tompkins 
> wrote:
> >
> > >>>
> >
> > 
> >
> > > On May 24, 2017, at 2:49 AM, Gary Gregory 
> >
> >  wrote:
> >
> > >
> >
> > > When I build with the IBM JDK 8 that IBM includes with some Eclipse
> >
> >  version
> >
> > > I have laying around, I indeed get:
> >
> > >
> >
> > > java (2)
> >
> > > org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest
> >
> > > testLang1219(org.apache.commons.lang3.time.FastDateParser_Ti
> >
> >  meZoneStrategyTest)
> >
> > > java.text.ParseException: Unparseable date: 26.10.2014 02:00:00
> MESZ
> >
> > 
> >
> > >>>
> >
> > >>> As I mentioned, the above test passes with the current IBM SDK 8:
> >
> > >>>
> >
> > >>> Java(TM) SE Runtime Environment (build pwi3280sr4fp5-20170421_01(SR4
> FP5))
> >
> > >>> IBM J9 VM (build 2.8, JRE 1.8.0 Windows 10 x86-32 20170419_344392
> (JIT
> >
> > >>> enabled, AOT enabled)
> >
> > >>> J9VM - R28_20170419_1004_B344392
> >
> > >>> JIT  - tr.r14.java_20170419_344392
> >
> > >>> GC  - R28_20170419_1004_B344392
> >
> > >>> J9CL - 20170419_344392)
> >
> > >>> JCL - 20170420_01 based on Oracle jdk8u131-b11
> >
> > >>>
> >
> > >>> So IMO the only test we should look at is:
> >
> > >>>
> >
> >  org.apache.commons.lang3.builder.ToStringBuilderTest
> >
> >  testReflectionHierarchyArrayList(org.apache.commons.lang3.bu
> >
> > >>> ilder.ToStringBuilderTest)
> >
> >  org.junit.ComparisonFailure:
> >
> >  expected:<...700dfa[elementData={[,,,<
> >
> > >>> null>,,]},size=0,
> modCount=0]>
> >
> >  but was:<...700dfa[elementData={[]},size=0,modCount=0]>
> >
> > >>>
> >
> > >>
> >
> > >> Looking at this a little more, I would say that IBM Java changed how
> it
> >
> > >> implemented ArrayList between it's 1.6 and 1.8 releases. I only have
> the
> >
> > >> current 1.8 IBM release. I cannot verify that this test makes sense on
> IBM
> >
> > >> 1.6. I propose we update the test to reflect IBM Java 8 and document
> the
> >
> > >> test as such.
> >
> > >
> >
> > > If the test makes assumptions about how ArrayList is implemented, then
> >
> > > I would say the test is wrong.
> >
> > >
> >
> > > If possible it should be fixed so as to work regardless of the
> >
> > > implementation details.
> >
> > > Rather than changing the test to work with a different version of the
> >
> > > implementation.
> >
> >
> > I don’t even have an IBM JDK and I don’t want to subscribe on their
> homepage just to get one. Does somebody know where to get an IBM JDK that
> works on Mac OS?
> >
> >
> > 

[Commons Wiki] Update of "MovingToGit" by BenediktRitter

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Commons Wiki" for 
change notification.

The "MovingToGit" page has been changed by BenediktRitter:
https://wiki.apache.org/commons/MovingToGit?action=diff=6=7

Comment:
Better formatting

  
  == Migrate code to new repository ==
  
- 1. Clone the new Git repository: git clone 
https://git-wip-us.apache.org/repos/asf/commons-foo.git
+  1. Clone the new Git repository: git clone 
https://git-wip-us.apache.org/repos/asf/commons-foo.git
- 2. Add the already existing GitHub mirror as new remote: git remote add 
GitHub g...@github.com:apache/commons-foo.git
+  2. Add the already existing GitHub mirror as new remote: git remote add 
GitHub g...@github.com:apache/commons-foo.git
- 3. Create the master branch: git checkout -b master
+  3. Create the master branch: git checkout -b master
- 4. Add all commits from the mirrored trunk branch from the GitHub mirror to 
the master branch: git fetch github trunk && git merge github/trunk
+  4. Add all commits from the mirrored trunk branch from the GitHub mirror to 
the master branch: git fetch github trunk && git merge github/trunk
- 5. Add all other branches and tags to your local repository
+  5. Add all other branches and tags to your local repository
- 6. push everything to the new repository
+  6. push everything to the new repository
  
  == Update pom and website ==
  

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

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Rob Tompkins]

+1 (non-binding)
Signatures ok
mvn clean site works in distro. 

> On Jun 8, 2017, at 1:09 PM, Gary Gregory  wrote:
> 
>> On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
>> 
>>> On 8 June 2017 at 17:19, Gary Gregory  wrote:
 On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero  wrote:
 
 [A Note, not a vote :) ]
 
 1. Clirr is generally considered obsolete, as it hadn't been worked on
>> for
 about ten years.   japicmp is a good replacement, especially for report
 generation, and is used in other commons projects.
 
>>> 
>>> IIRC, we've started using japicm here and there. Each component can
>> decide.
>>> But yes, Clirr looks pretty dead.
>>> 
>>> 
 2. Are the "changes" to the values in CharEncoding really necessary[1]
>> (The
 deprecation surely is). Technically this is a potentially breaking
>> binary
 incompatible change, as constant strings and primitives are inlined at
 compile time. [2]
 In this particular case, the results of load-time evaluation of the new
 initialization expressions  are identical to the old constants, so it's
 behaviourally compatible; however, since this is the case, and since
>> it's
 all deprecated anyway, why not leave the old values in-place?
 
>>> 
>>> The changes are not "necessary" that for sure and we do get Clirr
>> warnings:
>>> 
>>> Value of field ISO_8859_1 is no longer a compile-time constant
>>> Value of field US_ASCII is no longer a compile-time constant
>>> Value of field UTF_16 is no longer a compile-time constant
>>> Value of field UTF_16BE is no longer a compile-time constant
>>> Value of field UTF_16LE is no longer a compile-time constant
>>> Value of field UTF_8 is no longer a compile-time constant
>>> 
>>> It's source compatible. What is the issue at runtime that could hurt
>> users?
>> 
>> As the OP wrote, constants are inlined by the compiler.
>> So unless all code is recompiled, if it referenced the constant it may
>> have a stale value.
>> That is not binary compatible.
>> 
> 
> But in this case the actual values are the same are they not? So what is
> the difference? Would this only be a problem if we changed the string
> values? Which we can't since these are defined in the JRE. And the JRE is
> unlikely to change those.
> 
> Gary
> 
> 
>> 
>>> 
 3. JDK9 adds some extra parameters to the Deprecated annotation (most
 notably  forRemoval=true, which is used to indicate that the annotated
>> item
 is really really deprecated.)   It's not needed in this case, but is
>> worth
 thinking about  when jdk9 is eventually released (latest schedule
>> change :
 from 7/27/2017 to 9/21/2017).
 
>>> 
>>> I do not think we plan on making Java 9 a requirement for any current
>>> project.
>>> 
>>> Gary
>>> 
>>> 
 
 Simon
 
 [1]  https://github.com/apache/commons-lang/commit/7c19a1ff4c217
 f03c0be62baf1169d689f566825#diff-820a48456e11e85bf6cf5356c1aed4baR48
 
 [2] https://docs.oracle.com/javase/specs/jls/se8/html/jls-
 13.html#jls-13.4.9
 
> On Jun 8, 2017 4:48 AM, "Benedikt Ritter"  wrote:
> 
> Hello,
> 
> we have fixed quite a few bugs and added some nice new features since
> Commons Lang 3.5 was released, so I would like to release Commons Lang
 3.6
> based on RC3.
> The following issues have been fixed since RC2:
> 
> - Site build now works from source distribution
> - IBM JDK test failures have been fixed
> - Automatic-Module-Name MANIFEST entry has been added for Java 9
> compatibility
> 
> Commons Lang 3.6 R3 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/lang (svn revision
 19928)
> 
> The tag is here:
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=
> e454e79463ffbbd9114db43019dd211debbcc105
> 
> Commit ID the tag points at:
> 360198dfb6a2d68f1702f616dfacee34ae0541bb
> 
> Maven Artifacts:
> https://repository.apache.org/content/repositories/
 orgapachecommons-1250
> 
> These are the Maven artifacts and their hashes:
> 
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar
> (SHA1: c8adadb6c0b56c73f2cc2b4c77a09bfe34ec3a66)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
>> sources.jar.asc
> (SHA1: 46347c179ca9246d146d653bdc7363bda6f17d44)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom.asc
> (SHA1: 1309d4f3dd41a01ff9dd1f3c1a6eee10dad1ef77)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom
> (SHA1: 0fb4499188c94c63b3cba44f12481e193708c4a8)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar.asc
> (SHA1: e67e7d44751f1e346c2fda496193cbe251cfe098)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
>> javadoc.jar.asc
> (SHA1: 

[Commons Wiki] Update of "MovingToGit" by BenediktRitter

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Commons Wiki" for 
change notification.

The "MovingToGit" page has been changed by BenediktRitter:
https://wiki.apache.org/commons/MovingToGit?action=diff=5=6

Comment:
Describe what to do in order to migrate code from svn to git

  == Request a new Git repository ==
  
  Requesting git repositories is managed by an Infra self-service which is 
located at http://reporeq.apache.org. Go to that website an request the new git 
repository. Note, that the repository name has to be the component name. So for 
example for Commons CLI, the repository name had to be "cli". This generated 
"commons-cli" as generated name.
+ 
+ == Migrate code to new repository ==
+ 
+ 1. Clone the new Git repository: git clone 
https://git-wip-us.apache.org/repos/asf/commons-foo.git
+ 2. Add the already existing GitHub mirror as new remote: git remote add 
GitHub g...@github.com:apache/commons-foo.git
+ 3. Create the master branch: git checkout -b master
+ 4. Add all commits from the mirrored trunk branch from the GitHub mirror to 
the master branch: git fetch github trunk && git merge github/trunk
+ 5. Add all other branches and tags to your local repository
+ 6. push everything to the new repository
  
  == Update pom and website ==
  

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

[Commons Wiki] Update of "MovingToGit" by BenediktRitter

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Commons Wiki" for 
change notification.

The "MovingToGit" page has been changed by BenediktRitter:
https://wiki.apache.org/commons/MovingToGit?action=diff=4=5

Comment:
Document how to request git repositories

  Notes on things to look out for if a component moves from SVN to Git.
  
   * This is a work in progress *
+ 
+ == Request a new Git repository ==
+ 
+ Requesting git repositories is managed by an Infra self-service which is 
located at http://reporeq.apache.org. Go to that website an request the new git 
repository. Note, that the repository name has to be the component name. So for 
example for Commons CLI, the repository name had to be "cli". This generated 
"commons-cli" as generated name.
  
  == Update pom and website ==
  

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

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Gary Gregory]

On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:

> On 8 June 2017 at 17:19, Gary Gregory  wrote:
> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero  wrote:
> >
> >> [A Note, not a vote :) ]
> >>
> >> 1. Clirr is generally considered obsolete, as it hadn't been worked on
> for
> >> about ten years.   japicmp is a good replacement, especially for report
> >> generation, and is used in other commons projects.
> >>
> >
> > IIRC, we've started using japicm here and there. Each component can
> decide.
> > But yes, Clirr looks pretty dead.
> >
> >
> >> 2. Are the "changes" to the values in CharEncoding really necessary[1]
> (The
> >> deprecation surely is). Technically this is a potentially breaking
> binary
> >> incompatible change, as constant strings and primitives are inlined at
> >> compile time. [2]
> >> In this particular case, the results of load-time evaluation of the new
> >> initialization expressions  are identical to the old constants, so it's
> >> behaviourally compatible; however, since this is the case, and since
> it's
> >> all deprecated anyway, why not leave the old values in-place?
> >>
> >
> > The changes are not "necessary" that for sure and we do get Clirr
> warnings:
> >
> > Value of field ISO_8859_1 is no longer a compile-time constant
> > Value of field US_ASCII is no longer a compile-time constant
> > Value of field UTF_16 is no longer a compile-time constant
> > Value of field UTF_16BE is no longer a compile-time constant
> > Value of field UTF_16LE is no longer a compile-time constant
> > Value of field UTF_8 is no longer a compile-time constant
> >
> > It's source compatible. What is the issue at runtime that could hurt
> users?
>
> As the OP wrote, constants are inlined by the compiler.
> So unless all code is recompiled, if it referenced the constant it may
> have a stale value.
> That is not binary compatible.
>

But in this case the actual values are the same are they not? So what is
the difference? Would this only be a problem if we changed the string
values? Which we can't since these are defined in the JRE. And the JRE is
unlikely to change those.

Gary


>
> >
> >> 3. JDK9 adds some extra parameters to the Deprecated annotation (most
> >> notably  forRemoval=true, which is used to indicate that the annotated
> item
> >> is really really deprecated.)   It's not needed in this case, but is
> worth
> >> thinking about  when jdk9 is eventually released (latest schedule
> change :
> >> from 7/27/2017 to 9/21/2017).
> >>
> >
> > I do not think we plan on making Java 9 a requirement for any current
> > project.
> >
> > Gary
> >
> >
> >>
> >> Simon
> >>
> >> [1]  https://github.com/apache/commons-lang/commit/7c19a1ff4c217
> >> f03c0be62baf1169d689f566825#diff-820a48456e11e85bf6cf5356c1aed4baR48
> >>
> >> [2] https://docs.oracle.com/javase/specs/jls/se8/html/jls-
> >> 13.html#jls-13.4.9
> >>
> >> On Jun 8, 2017 4:48 AM, "Benedikt Ritter"  wrote:
> >>
> >> > Hello,
> >> >
> >> > we have fixed quite a few bugs and added some nice new features since
> >> > Commons Lang 3.5 was released, so I would like to release Commons Lang
> >> 3.6
> >> > based on RC3.
> >> > The following issues have been fixed since RC2:
> >> >
> >> > - Site build now works from source distribution
> >> > - IBM JDK test failures have been fixed
> >> > - Automatic-Module-Name MANIFEST entry has been added for Java 9
> >> > compatibility
> >> >
> >> > Commons Lang 3.6 R3 is available for review here:
> >> >  https://dist.apache.org/repos/dist/dev/commons/lang (svn revision
> >> 19928)
> >> >
> >> > The tag is here:
> >> > https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=
> >> > e454e79463ffbbd9114db43019dd211debbcc105
> >> >
> >> > Commit ID the tag points at:
> >> >  360198dfb6a2d68f1702f616dfacee34ae0541bb
> >> >
> >> > Maven Artifacts:
> >> >  https://repository.apache.org/content/repositories/
> >> orgapachecommons-1250
> >> >
> >> > These are the Maven artifacts and their hashes:
> >> >
> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar
> >> > (SHA1: c8adadb6c0b56c73f2cc2b4c77a09bfe34ec3a66)
> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> sources.jar.asc
> >> > (SHA1: 46347c179ca9246d146d653bdc7363bda6f17d44)
> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom.asc
> >> > (SHA1: 1309d4f3dd41a01ff9dd1f3c1a6eee10dad1ef77)
> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom
> >> > (SHA1: 0fb4499188c94c63b3cba44f12481e193708c4a8)
> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar.asc
> >> > (SHA1: e67e7d44751f1e346c2fda496193cbe251cfe098)
> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> javadoc.jar.asc
> >> > (SHA1: 6b19fa12d319ced69c0f8a27001569514711f9dc)
> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar
> >> > (SHA1: f89c1df082d6f67cb7c956715c56d7e7a0508d0a)
> >> > 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Gary Gregory]

+1.
>From src zip: ASC, MD5, SHA1 OK. RAT and Clirr OK. Clirr does have the
warnings discussed on this thread.
Running 'mvn clean site' passes with:

Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T12:39:06-07:00)
Maven home: C:\Java\apache-maven-3.5.0\bin\..
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_131\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

and:

java version "1.8.0"
Java(TM) SE Runtime Environment (build pwi3280sr4fp5-20170421_01(SR4 FP5))
IBM J9 VM (build 2.8, JRE 1.8.0 Windows 10 x86-32 20170419_344392 (JIT
enabled, AOT enabled)
J9VM - R28_20170419_1004_B344392
JIT  - tr.r14.java_20170419_344392
GC   - R28_20170419_1004_B344392
J9CL - 20170419_344392)
JCL - 20170420_01 based on Oracle jdk8u131-b11

But runs out of memory building the site with Oracle Java 7's default
settings.

Gary

On Thu, Jun 8, 2017 at 1:48 AM, Benedikt Ritter  wrote:

> Hello,
>
> we have fixed quite a few bugs and added some nice new features since
> Commons Lang 3.5 was released, so I would like to release Commons Lang 3.6
> based on RC3.
> The following issues have been fixed since RC2:
>
> - Site build now works from source distribution
> - IBM JDK test failures have been fixed
> - Automatic-Module-Name MANIFEST entry has been added for Java 9
> compatibility
>
> Commons Lang 3.6 R3 is available for review here:
>  https://dist.apache.org/repos/dist/dev/commons/lang (svn revision 19928)
>
> The tag is here:
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=
> e454e79463ffbbd9114db43019dd211debbcc105
>
> Commit ID the tag points at:
>  360198dfb6a2d68f1702f616dfacee34ae0541bb
>
> Maven Artifacts:
>  https://repository.apache.org/content/repositories/orgapachecommons-1250
>
> These are the Maven artifacts and their hashes:
>
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar
> (SHA1: c8adadb6c0b56c73f2cc2b4c77a09bfe34ec3a66)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar.asc
> (SHA1: 46347c179ca9246d146d653bdc7363bda6f17d44)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom.asc
> (SHA1: 1309d4f3dd41a01ff9dd1f3c1a6eee10dad1ef77)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom
> (SHA1: 0fb4499188c94c63b3cba44f12481e193708c4a8)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar.asc
> (SHA1: e67e7d44751f1e346c2fda496193cbe251cfe098)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar.asc
> (SHA1: 6b19fa12d319ced69c0f8a27001569514711f9dc)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar
> (SHA1: f89c1df082d6f67cb7c956715c56d7e7a0508d0a)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar
> (SHA1: e58ba08b01d37a023746f0987dcd910036a63021)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar.asc
> (SHA1: af050e8c29a801a5d6783268c56230b814f56240)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> test-sources.jar.asc
> (SHA1: 71e4c11efb9e3b2eff402ba4648d21822fb8da4a)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-test-sources.jar
> (SHA1: 04a0fc8293d4ed64a54dcc9ba5f996776a4657ea)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar
> (SHA1: 87993a16c14a251062e3fe860fa53b5ef5304a0f)
>
> I have tested this with JDK 7, JDK 8 and JDK 9 EA b172 using Maven 3.5.0.
>
> Details of changes since 3.5 are in the release notes:
>https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE-NOTES.txt
>http://home.apache.org/~britter/commons/lang/LANG_3_6_
> RC3/changes-report.html
>
> Site:
>  http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3
>  (note some *relative* links are broken and the 3.6 directories are
>  not yet created - these will be OK once the site is deployed)
>
> Clirr Report (compared to 3.5):
>http://home.apache.org/~britter/commons/lang/LANG_3_6_
> RC3/clirr-report.html
>
> RAT Report:
>http://home.apache.org/~britter/commons/lang/LANG_3_6_
> RC3/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,
> i.e. sometime after 11:00 CEST (UTC+2) 11-June 2017
>
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
>
> Thanks!
> Benedikt
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[sebb]

On 8 June 2017 at 17:19, Gary Gregory  wrote:
> On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero  wrote:
>
>> [A Note, not a vote :) ]
>>
>> 1. Clirr is generally considered obsolete, as it hadn't been worked on for
>> about ten years.   japicmp is a good replacement, especially for report
>> generation, and is used in other commons projects.
>>
>
> IIRC, we've started using japicm here and there. Each component can decide.
> But yes, Clirr looks pretty dead.
>
>
>> 2. Are the "changes" to the values in CharEncoding really necessary[1] (The
>> deprecation surely is). Technically this is a potentially breaking binary
>> incompatible change, as constant strings and primitives are inlined at
>> compile time. [2]
>> In this particular case, the results of load-time evaluation of the new
>> initialization expressions  are identical to the old constants, so it's
>> behaviourally compatible; however, since this is the case, and since  it's
>> all deprecated anyway, why not leave the old values in-place?
>>
>
> The changes are not "necessary" that for sure and we do get Clirr warnings:
>
> Value of field ISO_8859_1 is no longer a compile-time constant
> Value of field US_ASCII is no longer a compile-time constant
> Value of field UTF_16 is no longer a compile-time constant
> Value of field UTF_16BE is no longer a compile-time constant
> Value of field UTF_16LE is no longer a compile-time constant
> Value of field UTF_8 is no longer a compile-time constant
>
> It's source compatible. What is the issue at runtime that could hurt users?

As the OP wrote, constants are inlined by the compiler.
So unless all code is recompiled, if it referenced the constant it may
have a stale value.
That is not binary compatible.

>
>> 3. JDK9 adds some extra parameters to the Deprecated annotation (most
>> notably  forRemoval=true, which is used to indicate that the annotated item
>> is really really deprecated.)   It's not needed in this case, but is worth
>> thinking about  when jdk9 is eventually released (latest schedule change :
>> from 7/27/2017 to 9/21/2017).
>>
>
> I do not think we plan on making Java 9 a requirement for any current
> project.
>
> Gary
>
>
>>
>> Simon
>>
>> [1]  https://github.com/apache/commons-lang/commit/7c19a1ff4c217
>> f03c0be62baf1169d689f566825#diff-820a48456e11e85bf6cf5356c1aed4baR48
>>
>> [2] https://docs.oracle.com/javase/specs/jls/se8/html/jls-
>> 13.html#jls-13.4.9
>>
>> On Jun 8, 2017 4:48 AM, "Benedikt Ritter"  wrote:
>>
>> > Hello,
>> >
>> > we have fixed quite a few bugs and added some nice new features since
>> > Commons Lang 3.5 was released, so I would like to release Commons Lang
>> 3.6
>> > based on RC3.
>> > The following issues have been fixed since RC2:
>> >
>> > - Site build now works from source distribution
>> > - IBM JDK test failures have been fixed
>> > - Automatic-Module-Name MANIFEST entry has been added for Java 9
>> > compatibility
>> >
>> > Commons Lang 3.6 R3 is available for review here:
>> >  https://dist.apache.org/repos/dist/dev/commons/lang (svn revision
>> 19928)
>> >
>> > The tag is here:
>> > https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=
>> > e454e79463ffbbd9114db43019dd211debbcc105
>> >
>> > Commit ID the tag points at:
>> >  360198dfb6a2d68f1702f616dfacee34ae0541bb
>> >
>> > Maven Artifacts:
>> >  https://repository.apache.org/content/repositories/
>> orgapachecommons-1250
>> >
>> > These are the Maven artifacts and their hashes:
>> >
>> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar
>> > (SHA1: c8adadb6c0b56c73f2cc2b4c77a09bfe34ec3a66)
>> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar.asc
>> > (SHA1: 46347c179ca9246d146d653bdc7363bda6f17d44)
>> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom.asc
>> > (SHA1: 1309d4f3dd41a01ff9dd1f3c1a6eee10dad1ef77)
>> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom
>> > (SHA1: 0fb4499188c94c63b3cba44f12481e193708c4a8)
>> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar.asc
>> > (SHA1: e67e7d44751f1e346c2fda496193cbe251cfe098)
>> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar.asc
>> > (SHA1: 6b19fa12d319ced69c0f8a27001569514711f9dc)
>> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar
>> > (SHA1: f89c1df082d6f67cb7c956715c56d7e7a0508d0a)
>> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar
>> > (SHA1: e58ba08b01d37a023746f0987dcd910036a63021)
>> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar.asc
>> > (SHA1: af050e8c29a801a5d6783268c56230b814f56240)
>> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
>> > test-sources.jar.asc
>> > (SHA1: 71e4c11efb9e3b2eff402ba4648d21822fb8da4a)
>> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-test-sources.jar
>> > (SHA1: 04a0fc8293d4ed64a54dcc9ba5f996776a4657ea)
>> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar

Re: [VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Rob Tompkins]

> On Jun 8, 2017, at 11:02 AM, Matt Sicker  wrote:
> 
> Adding the appropriate key to the KEYS file after the fact should still
> work. It would have the same cryptographic reliability as being added
> beforehand as you can't exactly imitate a key.

Yes (mine has been up there since February actually), but the signature and the 
time stamp on the files didn't match me. Bad svn commit on my part initially. 
Doh. 

> 
>> On 8 June 2017 at 07:17, Rob Tompkins  wrote:
>> 
>> 
>> 
 On Jun 8, 2017, at 8:09 AM, sebb  wrote:
 
 On 8 June 2017 at 01:20, Gary Gregory  wrote:
 The ASC does not seem to have a public key.:
 
 gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
>>> 
>>> That is not the recommended way to check a sig; you also need the target
>> file
>>> 
>>> $ gpg --verify downloaded_file.asc downloaded_file
>> 
>> Indeed, but if you don't specify it looks in the current directory for the
>> file.
>> 
>>> 
 gpg: assuming signed data in 'commons-fileupload-1.3.3-
>> source-release.zip'
>>> 
>>> Note that gpg is assuming where to find the data.
>>> 
 gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA
>> key
 ID 7188601C
 *gpg: Can't check signature: No public key*
>>> 
>>> However if the .asc file was not detached, gpg would not check the
>> target file.
>>> 
>>> https://www.apache.org/info/verification.html#specify_both
>>> 
 
 Also, the file naming should be consistent,
 https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has
>> both
 "source-release" and "src". Not sure how you can end up with the
 differences beyond just the file extension.
 
 Gary
 
 
> On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins 
>> wrote:
> 
> Hello all,
> 
> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from
>> RC5).
> 
> Tag name:
>  commons-fileupload-1.3.3-RC5 (signature can be checked from git using
> 'git tag -v')
> 
> Tag URL:
>  https://git-wip-us.apache.org/repos/asf?p=commons-
> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
> 
> Commit ID the tag points at:
>  dd2238b1671644cfead0e87c24a8ac61b4039084
> 
> Site:
>  http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
> 
> Distribution files (committed at revision 19901):
>  https://dist.apache.org/repos/dist/dev/commons/fileupload/
> 
> Distribution files hashes (SHA1):
>  commons-fileupload-1.3.3-bin.tar.gz
>  (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
>  commons-fileupload-1.3.3-bin.zip
>  (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
>  commons-fileupload-1.3.3-src.tar.gz
>  (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
>  commons-fileupload-1.3.3-src.zip
>  (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
> 
> These are the Maven artifacts and their hashes:
>  commons-fileupload-1.3.3-javadoc.jar
>  (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
>  commons-fileupload-1.3.3-sources.jar
>  (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
>  commons-fileupload-1.3.3-test-sources.jar
>  (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
>  commons-fileupload-1.3.3-tests.jar
>  (SHA1: 20510147958fc759582e6ede789ccf31d056b232)
>  commons-fileupload-1.3.3.jar
>  (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
>  commons-fileupload-1.3.3.pom
>  (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
> 
> KEYS file to check signatures:
>  http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
>  https://repository.apache.org/content/repositories/
> orgapachecommons-1249
> 
> Please select one of the following options[1]:
> [ ] +1 Release it.
> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
> 
> This vote will be open at least 72 hours, i.e. until
> 2017-06-09T19:00:00Z
> (this is UTC time).
> 
> 
> Cheers,
> -Rob
> 
> [1] http://apache.org/foundation/voting.html
> -
> 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
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
> 
> 
> -- 
> Matt Sicker 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Gary Gregory]

On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero  wrote:

> [A Note, not a vote :) ]
>
> 1. Clirr is generally considered obsolete, as it hadn't been worked on for
> about ten years.   japicmp is a good replacement, especially for report
> generation, and is used in other commons projects.
>

IIRC, we've started using japicm here and there. Each component can decide.
But yes, Clirr looks pretty dead.


> 2. Are the "changes" to the values in CharEncoding really necessary[1] (The
> deprecation surely is). Technically this is a potentially breaking binary
> incompatible change, as constant strings and primitives are inlined at
> compile time. [2]
> In this particular case, the results of load-time evaluation of the new
> initialization expressions  are identical to the old constants, so it's
> behaviourally compatible; however, since this is the case, and since  it's
> all deprecated anyway, why not leave the old values in-place?
>

The changes are not "necessary" that for sure and we do get Clirr warnings:

Value of field ISO_8859_1 is no longer a compile-time constant
Value of field US_ASCII is no longer a compile-time constant
Value of field UTF_16 is no longer a compile-time constant
Value of field UTF_16BE is no longer a compile-time constant
Value of field UTF_16LE is no longer a compile-time constant
Value of field UTF_8 is no longer a compile-time constant

It's source compatible. What is the issue at runtime that could hurt users?


> 3. JDK9 adds some extra parameters to the Deprecated annotation (most
> notably  forRemoval=true, which is used to indicate that the annotated item
> is really really deprecated.)   It's not needed in this case, but is worth
> thinking about  when jdk9 is eventually released (latest schedule change :
> from 7/27/2017 to 9/21/2017).
>

I do not think we plan on making Java 9 a requirement for any current
project.

Gary


>
> Simon
>
> [1]  https://github.com/apache/commons-lang/commit/7c19a1ff4c217
> f03c0be62baf1169d689f566825#diff-820a48456e11e85bf6cf5356c1aed4baR48
>
> [2] https://docs.oracle.com/javase/specs/jls/se8/html/jls-
> 13.html#jls-13.4.9
>
> On Jun 8, 2017 4:48 AM, "Benedikt Ritter"  wrote:
>
> > Hello,
> >
> > we have fixed quite a few bugs and added some nice new features since
> > Commons Lang 3.5 was released, so I would like to release Commons Lang
> 3.6
> > based on RC3.
> > The following issues have been fixed since RC2:
> >
> > - Site build now works from source distribution
> > - IBM JDK test failures have been fixed
> > - Automatic-Module-Name MANIFEST entry has been added for Java 9
> > compatibility
> >
> > Commons Lang 3.6 R3 is available for review here:
> >  https://dist.apache.org/repos/dist/dev/commons/lang (svn revision
> 19928)
> >
> > The tag is here:
> > https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=
> > e454e79463ffbbd9114db43019dd211debbcc105
> >
> > Commit ID the tag points at:
> >  360198dfb6a2d68f1702f616dfacee34ae0541bb
> >
> > Maven Artifacts:
> >  https://repository.apache.org/content/repositories/
> orgapachecommons-1250
> >
> > These are the Maven artifacts and their hashes:
> >
> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar
> > (SHA1: c8adadb6c0b56c73f2cc2b4c77a09bfe34ec3a66)
> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar.asc
> > (SHA1: 46347c179ca9246d146d653bdc7363bda6f17d44)
> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom.asc
> > (SHA1: 1309d4f3dd41a01ff9dd1f3c1a6eee10dad1ef77)
> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom
> > (SHA1: 0fb4499188c94c63b3cba44f12481e193708c4a8)
> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar.asc
> > (SHA1: e67e7d44751f1e346c2fda496193cbe251cfe098)
> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar.asc
> > (SHA1: 6b19fa12d319ced69c0f8a27001569514711f9dc)
> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar
> > (SHA1: f89c1df082d6f67cb7c956715c56d7e7a0508d0a)
> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar
> > (SHA1: e58ba08b01d37a023746f0987dcd910036a63021)
> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar.asc
> > (SHA1: af050e8c29a801a5d6783268c56230b814f56240)
> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> > test-sources.jar.asc
> > (SHA1: 71e4c11efb9e3b2eff402ba4648d21822fb8da4a)
> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-test-sources.jar
> > (SHA1: 04a0fc8293d4ed64a54dcc9ba5f996776a4657ea)
> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar
> > (SHA1: 87993a16c14a251062e3fe860fa53b5ef5304a0f)
> >
> > I have tested this with JDK 7, JDK 8 and JDK 9 EA b172 using Maven 3.5.0.
> >
> > Details of changes since 3.5 are in the release notes:
> >https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE-NOTES.txt
> >http://home.apache.org/~britter/commons/lang/LANG_3_6_
> > RC3/changes-report.html
> >
> > 

Re: [VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Gary Gregory]

+1

>From src zip: ASC, MD5, SHA1 OK.

Build passes with 'mvn clean site'.

Tests, CLIRR, RAT and reports OK.

Used:

Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T12:39:06-07:00)
Maven home: C:\Java\apache-maven-3.5.0\bin\..
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_80\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"

Gary

On Thu, Jun 8, 2017 at 8:55 AM, Gary Gregory  wrote:

>
>
> On Thu, Jun 8, 2017 at 5:17 AM, Rob Tompkins  wrote:
>
>>
>>
>> > On Jun 8, 2017, at 8:09 AM, sebb  wrote:
>> >
>> >> On 8 June 2017 at 01:20, Gary Gregory  wrote:
>> >> The ASC does not seem to have a public key.:
>> >>
>> >> gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
>> >
>> > That is not the recommended way to check a sig; you also need the
>> target file
>> >
>> > $ gpg --verify downloaded_file.asc downloaded_file
>>
>> Indeed, but if you don't specify it looks in the current directory for
>> the file.
>>
>
> Works like a charm now:
>
> $ gpg --verify commons-fileupload-1.3.3-src.zip.asc
> commons-fileupload-1.3.3-src.zip
> gpg: Signature made 06/06/17 17:31:41 ric using RSA key ID 5ECBB314
> gpg: Good signature from "Rob Tompkins " [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the
> owner.
> Primary key fingerprint: B6E7 3D84 EA4F CC47 1660  8725 3FAA D2CD 5ECB B314
>
> Gary
>
>
>>
>> >
>> >> gpg: assuming signed data in 'commons-fileupload-1.3.3-sour
>> ce-release.zip'
>> >
>> > Note that gpg is assuming where to find the data.
>> >
>> >> gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA
>> key
>> >> ID 7188601C
>> >> *gpg: Can't check signature: No public key*
>> >
>> > However if the .asc file was not detached, gpg would not check the
>> target file.
>> >
>> > https://www.apache.org/info/verification.html#specify_both
>> >
>> >>
>> >> Also, the file naming should be consistent,
>> >> https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has
>> both
>> >> "source-release" and "src". Not sure how you can end up with the
>> >> differences beyond just the file extension.
>> >>
>> >> Gary
>> >>
>> >>
>> >>> On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins 
>> wrote:
>> >>>
>> >>> Hello all,
>> >>>
>> >>> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from
>> RC5).
>> >>>
>> >>> Tag name:
>> >>>   commons-fileupload-1.3.3-RC5 (signature can be checked from git
>> using
>> >>> 'git tag -v')
>> >>>
>> >>> Tag URL:
>> >>>   https://git-wip-us.apache.org/repos/asf?p=commons-
>> >>> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
>> >>>
>> >>> Commit ID the tag points at:
>> >>>   dd2238b1671644cfead0e87c24a8ac61b4039084
>> >>>
>> >>> Site:
>> >>>   http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
>> >>>
>> >>> Distribution files (committed at revision 19901):
>> >>>   https://dist.apache.org/repos/dist/dev/commons/fileupload/
>> >>>
>> >>> Distribution files hashes (SHA1):
>> >>>   commons-fileupload-1.3.3-bin.tar.gz
>> >>>   (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
>> >>>   commons-fileupload-1.3.3-bin.zip
>> >>>   (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
>> >>>   commons-fileupload-1.3.3-src.tar.gz
>> >>>   (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
>> >>>   commons-fileupload-1.3.3-src.zip
>> >>>   (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
>> >>>
>> >>> These are the Maven artifacts and their hashes:
>> >>>   commons-fileupload-1.3.3-javadoc.jar
>> >>>   (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
>> >>>   commons-fileupload-1.3.3-sources.jar
>> >>>   (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
>> >>>   commons-fileupload-1.3.3-test-sources.jar
>> >>>   (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
>> >>>   commons-fileupload-1.3.3-tests.jar
>> >>>   (SHA1: 20510147958fc759582e6ede789ccf31d056b232)
>> >>>   commons-fileupload-1.3.3.jar
>> >>>   (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
>> >>>   commons-fileupload-1.3.3.pom
>> >>>   (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
>> >>>
>> >>> KEYS file to check signatures:
>> >>>   http://www.apache.org/dist/commons/KEYS
>> >>>
>> >>> Maven artifacts:
>> >>>   https://repository.apache.org/content/repositories/
>> >>> orgapachecommons-1249
>> >>>
>> >>> Please select one of the following options[1]:
>> >>>  [ ] +1 Release it.
>> >>>  [ ] +0 Go ahead; I don't care.
>> >>>  [ ] -0 There are a few minor glitches: ...
>> >>>  [ ] -1 No, do not release it because ...
>> >>>
>> >>> This vote will be open at least 72 hours, i.e. until
>> >>> 2017-06-09T19:00:00Z
>> >>> (this is UTC time).
>> >>> 
>> >>>
>> >>> Cheers,
>> >>> -Rob
>> >>>
>> >>> [1] 

Re: [VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Gary Gregory]

On Thu, Jun 8, 2017 at 5:17 AM, Rob Tompkins  wrote:

>
>
> > On Jun 8, 2017, at 8:09 AM, sebb  wrote:
> >
> >> On 8 June 2017 at 01:20, Gary Gregory  wrote:
> >> The ASC does not seem to have a public key.:
> >>
> >> gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
> >
> > That is not the recommended way to check a sig; you also need the target
> file
> >
> > $ gpg --verify downloaded_file.asc downloaded_file
>
> Indeed, but if you don't specify it looks in the current directory for the
> file.
>

Works like a charm now:

$ gpg --verify commons-fileupload-1.3.3-src.zip.asc
commons-fileupload-1.3.3-src.zip
gpg: Signature made 06/06/17 17:31:41 ric using RSA key ID 5ECBB314
gpg: Good signature from "Rob Tompkins " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: B6E7 3D84 EA4F CC47 1660  8725 3FAA D2CD 5ECB B314

Gary


>
> >
> >> gpg: assuming signed data in 'commons-fileupload-1.3.3-
> source-release.zip'
> >
> > Note that gpg is assuming where to find the data.
> >
> >> gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA
> key
> >> ID 7188601C
> >> *gpg: Can't check signature: No public key*
> >
> > However if the .asc file was not detached, gpg would not check the
> target file.
> >
> > https://www.apache.org/info/verification.html#specify_both
> >
> >>
> >> Also, the file naming should be consistent,
> >> https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has
> both
> >> "source-release" and "src". Not sure how you can end up with the
> >> differences beyond just the file extension.
> >>
> >> Gary
> >>
> >>
> >>> On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins 
> wrote:
> >>>
> >>> Hello all,
> >>>
> >>> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from
> RC5).
> >>>
> >>> Tag name:
> >>>   commons-fileupload-1.3.3-RC5 (signature can be checked from git using
> >>> 'git tag -v')
> >>>
> >>> Tag URL:
> >>>   https://git-wip-us.apache.org/repos/asf?p=commons-
> >>> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
> >>>
> >>> Commit ID the tag points at:
> >>>   dd2238b1671644cfead0e87c24a8ac61b4039084
> >>>
> >>> Site:
> >>>   http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
> >>>
> >>> Distribution files (committed at revision 19901):
> >>>   https://dist.apache.org/repos/dist/dev/commons/fileupload/
> >>>
> >>> Distribution files hashes (SHA1):
> >>>   commons-fileupload-1.3.3-bin.tar.gz
> >>>   (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
> >>>   commons-fileupload-1.3.3-bin.zip
> >>>   (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
> >>>   commons-fileupload-1.3.3-src.tar.gz
> >>>   (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
> >>>   commons-fileupload-1.3.3-src.zip
> >>>   (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
> >>>
> >>> These are the Maven artifacts and their hashes:
> >>>   commons-fileupload-1.3.3-javadoc.jar
> >>>   (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
> >>>   commons-fileupload-1.3.3-sources.jar
> >>>   (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
> >>>   commons-fileupload-1.3.3-test-sources.jar
> >>>   (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
> >>>   commons-fileupload-1.3.3-tests.jar
> >>>   (SHA1: 20510147958fc759582e6ede789ccf31d056b232)
> >>>   commons-fileupload-1.3.3.jar
> >>>   (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
> >>>   commons-fileupload-1.3.3.pom
> >>>   (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
> >>>
> >>> KEYS file to check signatures:
> >>>   http://www.apache.org/dist/commons/KEYS
> >>>
> >>> Maven artifacts:
> >>>   https://repository.apache.org/content/repositories/
> >>> orgapachecommons-1249
> >>>
> >>> Please select one of the following options[1]:
> >>>  [ ] +1 Release it.
> >>>  [ ] +0 Go ahead; I don't care.
> >>>  [ ] -0 There are a few minor glitches: ...
> >>>  [ ] -1 No, do not release it because ...
> >>>
> >>> This vote will be open at least 72 hours, i.e. until
> >>> 2017-06-09T19:00:00Z
> >>> (this is UTC time).
> >>> 
> >>>
> >>> Cheers,
> >>> -Rob
> >>>
> >>> [1] http://apache.org/foundation/voting.html
> >>> -
> >>> 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
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [LANG] Fix date related test failures on IBM JDKs (Was: Re: [CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC2)

[Amey Jadiye]

Hi All/Gary/Benedikt/Bruno,

May be i'm late in this discussion, just had thought around ibmjdk8 that
can we add ibm-jdk8 in our travis.yml file for checking builds against it ?
might be helpful to avoid problem we fixed with LANG-1337

I was looking at the way we can do that because the fact that Travis don't
support ibm-jdk8, however proposal is raised [1] so hope we can get it in
future.   I also found the workaround till we get it here [2].

[1] https://github.com/travis-ci/travis-ci/issues/2682
[2] https://github.com/DanHeidinga/IBM-J9-DockerImage-For-TravisCI

Regards,
Amey

On Tue, Jun 6, 2017, 5:15 PM Bruno P. Kinoshita
 wrote:
>
> Actually, here it goes https://github.com/apache/commons-lang/pull/269.
>
> If anyone else with the latest IBM JDK 8 could test and confirm it works.
Worked for me on IBM JDK 8, Oracle JDK 7, and Oracle JDK 8; Ubuntu 16.04
LTS, Maven 3.3.9.
>
> Cheers
> Bruno
> 
> From: Bruno P. Kinoshita 
> To: Commons Developers List 
> Sent: Tuesday, 6 June 2017 10:13 PM
> Subject: Re: [LANG] Fix date related test failures on IBM JDKs (Was: Re:
[CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC2)
>
>
>
> I am downloading the latest IBM JDK in order to test other components
too, and might have some spare time this week to fix it, as I'm switching
jobs next week. But  happy if anyone beats me to it and finds the bug first
:)
>
> CheersBruno
>
>
>   From: Benedikt Ritter 
>
> To: Commons Developers List 
>
> Sent: Monday, 5 June 2017 10:54 PM
>
> Subject: [LANG] Fix date related test failures on IBM JDKs (Was: Re:
[CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC2)
>
>
>
> Hi,
>
>
> > Am 25.05.2017 um 13:16 schrieb sebb :
>
> >
>
> > On 25 May 2017 at 01:02, Gary Gregory  wrote:
>
> >> On Wed, May 24, 2017 at 4:46 PM, Gary Gregory 
>
> >> wrote:
>
> >>
>
> >>> On Wed, May 24, 2017 at 2:12 PM, Rob Tompkins 
wrote:
>
> >>>
>
> 
>
> > On May 24, 2017, at 2:49 AM, Gary Gregory 
>
>  wrote:
>
> >
>
> > When I build with the IBM JDK 8 that IBM includes with some Eclipse
>
>  version
>
> > I have laying around, I indeed get:
>
> >
>
> > java (2)
>
> > org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest
>
> > testLang1219(org.apache.commons.lang3.time.FastDateParser_Ti
>
>  meZoneStrategyTest)
>
> > java.text.ParseException: Unparseable date: 26.10.2014 02:00:00 MESZ
>
> 
>
> >>>
>
> >>> As I mentioned, the above test passes with the current IBM SDK 8:
>
> >>>
>
> >>> Java(TM) SE Runtime Environment (build pwi3280sr4fp5-20170421_01(SR4
FP5))
>
> >>> IBM J9 VM (build 2.8, JRE 1.8.0 Windows 10 x86-32 20170419_344392 (JIT
>
> >>> enabled, AOT enabled)
>
> >>> J9VM - R28_20170419_1004_B344392
>
> >>> JIT  - tr.r14.java_20170419_344392
>
> >>> GC  - R28_20170419_1004_B344392
>
> >>> J9CL - 20170419_344392)
>
> >>> JCL - 20170420_01 based on Oracle jdk8u131-b11
>
> >>>
>
> >>> So IMO the only test we should look at is:
>
> >>>
>
>  org.apache.commons.lang3.builder.ToStringBuilderTest
>
>  testReflectionHierarchyArrayList(org.apache.commons.lang3.bu
>
> >>> ilder.ToStringBuilderTest)
>
>  org.junit.ComparisonFailure:
>
>  expected:<...700dfa[elementData={[,,,<
>
> >>> null>,,]},size=0,modCount=0]>
>
>  but was:<...700dfa[elementData={[]},size=0,modCount=0]>
>
> >>>
>
> >>
>
> >> Looking at this a little more, I would say that IBM Java changed how it
>
> >> implemented ArrayList between it's 1.6 and 1.8 releases. I only have
the
>
> >> current 1.8 IBM release. I cannot verify that this test makes sense on
IBM
>
> >> 1.6. I propose we update the test to reflect IBM Java 8 and document
the
>
> >> test as such.
>
> >
>
> > If the test makes assumptions about how ArrayList is implemented, then
>
> > I would say the test is wrong.
>
> >
>
> > If possible it should be fixed so as to work regardless of the
>
> > implementation details.
>
> > Rather than changing the test to work with a different version of the
>
> > implementation.
>
>
> I don’t even have an IBM JDK and I don’t want to subscribe on their
homepage just to get one. Does somebody know where to get an IBM JDK that
works on Mac OS?
>
>
> Does anybody have an IBM JDK and has the time to fix this?
>
>
> Thank you,
>
> Benedikt
>
>
> >
>
> >> Gary
>
> >>
>
> >>>
>
> >>>
>
> >>> Gary
>
> >>>
>
> >>>
>
> >>>
>
>  Wondering if this change (https://github.com/apache/com
>
>  mons-lang/commit/eb2b89efbe15ab0b70fd94f0ecd0aa03866fb4d2#
>
>  diff-27e0ef6d1e59c634d3ba4d9cb05629a4R362 <
https://github.com/apache/com
>
>  mons-lang/commit/eb2b89efbe15ab0b70fd94f0ecd0aa03866fb4d2#
>
>  diff-27e0ef6d1e59c634d3ba4d9cb05629a4R362>) caused this one. It

[GitHub] commons-text issue #44: [TEXT-80]: Fixed confusing StrLookup API

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/44
  

[![Coverage 
Status](https://coveralls.io/builds/11887530/badge)](https://coveralls.io/builds/11887530)

Coverage remained the same at 96.653% when pulling 
**fff3f43d27ed831986b36691eaeb7570eaa94d63 on ameyjadiye:TEXT-80** into 
**5f498c0f4783d035bfeb77517731c948f8567b1e on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Matt Sicker]

Adding the appropriate key to the KEYS file after the fact should still
work. It would have the same cryptographic reliability as being added
beforehand as you can't exactly imitate a key.

On 8 June 2017 at 07:17, Rob Tompkins  wrote:

>
>
> > On Jun 8, 2017, at 8:09 AM, sebb  wrote:
> >
> >> On 8 June 2017 at 01:20, Gary Gregory  wrote:
> >> The ASC does not seem to have a public key.:
> >>
> >> gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
> >
> > That is not the recommended way to check a sig; you also need the target
> file
> >
> > $ gpg --verify downloaded_file.asc downloaded_file
>
> Indeed, but if you don't specify it looks in the current directory for the
> file.
>
> >
> >> gpg: assuming signed data in 'commons-fileupload-1.3.3-
> source-release.zip'
> >
> > Note that gpg is assuming where to find the data.
> >
> >> gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA
> key
> >> ID 7188601C
> >> *gpg: Can't check signature: No public key*
> >
> > However if the .asc file was not detached, gpg would not check the
> target file.
> >
> > https://www.apache.org/info/verification.html#specify_both
> >
> >>
> >> Also, the file naming should be consistent,
> >> https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has
> both
> >> "source-release" and "src". Not sure how you can end up with the
> >> differences beyond just the file extension.
> >>
> >> Gary
> >>
> >>
> >>> On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins 
> wrote:
> >>>
> >>> Hello all,
> >>>
> >>> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from
> RC5).
> >>>
> >>> Tag name:
> >>>   commons-fileupload-1.3.3-RC5 (signature can be checked from git using
> >>> 'git tag -v')
> >>>
> >>> Tag URL:
> >>>   https://git-wip-us.apache.org/repos/asf?p=commons-
> >>> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
> >>>
> >>> Commit ID the tag points at:
> >>>   dd2238b1671644cfead0e87c24a8ac61b4039084
> >>>
> >>> Site:
> >>>   http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
> >>>
> >>> Distribution files (committed at revision 19901):
> >>>   https://dist.apache.org/repos/dist/dev/commons/fileupload/
> >>>
> >>> Distribution files hashes (SHA1):
> >>>   commons-fileupload-1.3.3-bin.tar.gz
> >>>   (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
> >>>   commons-fileupload-1.3.3-bin.zip
> >>>   (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
> >>>   commons-fileupload-1.3.3-src.tar.gz
> >>>   (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
> >>>   commons-fileupload-1.3.3-src.zip
> >>>   (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
> >>>
> >>> These are the Maven artifacts and their hashes:
> >>>   commons-fileupload-1.3.3-javadoc.jar
> >>>   (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
> >>>   commons-fileupload-1.3.3-sources.jar
> >>>   (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
> >>>   commons-fileupload-1.3.3-test-sources.jar
> >>>   (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
> >>>   commons-fileupload-1.3.3-tests.jar
> >>>   (SHA1: 20510147958fc759582e6ede789ccf31d056b232)
> >>>   commons-fileupload-1.3.3.jar
> >>>   (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
> >>>   commons-fileupload-1.3.3.pom
> >>>   (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
> >>>
> >>> KEYS file to check signatures:
> >>>   http://www.apache.org/dist/commons/KEYS
> >>>
> >>> Maven artifacts:
> >>>   https://repository.apache.org/content/repositories/
> >>> orgapachecommons-1249
> >>>
> >>> Please select one of the following options[1]:
> >>>  [ ] +1 Release it.
> >>>  [ ] +0 Go ahead; I don't care.
> >>>  [ ] -0 There are a few minor glitches: ...
> >>>  [ ] -1 No, do not release it because ...
> >>>
> >>> This vote will be open at least 72 hours, i.e. until
> >>> 2017-06-09T19:00:00Z
> >>> (this is UTC time).
> >>> 
> >>>
> >>> Cheers,
> >>> -Rob
> >>>
> >>> [1] http://apache.org/foundation/voting.html
> >>> -
> >>> 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
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Matt Sicker 

[RESULT][VOTE][LAZY] Migrate Apache Commons CLI to git

[Benedikt Ritter]

Hi,

> Am 05.06.2017 um 13:20 schrieb Benedikt Ritter :
> 
> Hi,
> 
> I’d like to call a vote by lazy consensus for migrating the code base of 
> Apache Commons CLI to git.
> 
> This vote is successful if nobody raises objections within the next 72 hours, 
> e.g. until June-08-2017, 13:30 MESZ.

This vote passes with no objections and the following +1 votes:

- Amey Jadiye
- Gary Gregory

I will take care of the migration ASAP.

Thank you,
Benedikt

> 
> Regards,
> Benedikt
> 
> 
> -
> 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 Lang 3.6 based on RC3

[Simon Spero]

[A Note, not a vote :) ]

1. Clirr is generally considered obsolete, as it hadn't been worked on for
about ten years.   japicmp is a good replacement, especially for report
generation, and is used in other commons projects.

2. Are the "changes" to the values in CharEncoding really necessary[1] (The
deprecation surely is). Technically this is a potentially breaking binary
incompatible change, as constant strings and primitives are inlined at
compile time. [2]
In this particular case, the results of load-time evaluation of the new
initialization expressions  are identical to the old constants, so it's
behaviourally compatible; however, since this is the case, and since  it's
all deprecated anyway, why not leave the old values in-place?

3. JDK9 adds some extra parameters to the Deprecated annotation (most
notably  forRemoval=true, which is used to indicate that the annotated item
is really really deprecated.)   It's not needed in this case, but is worth
thinking about  when jdk9 is eventually released (latest schedule change :
from 7/27/2017 to 9/21/2017).

Simon

[1]  https://github.com/apache/commons-lang/commit/7c19a1ff4c217
f03c0be62baf1169d689f566825#diff-820a48456e11e85bf6cf5356c1aed4baR48

[2] https://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.4.9

On Jun 8, 2017 4:48 AM, "Benedikt Ritter"  wrote:

> Hello,
>
> we have fixed quite a few bugs and added some nice new features since
> Commons Lang 3.5 was released, so I would like to release Commons Lang 3.6
> based on RC3.
> The following issues have been fixed since RC2:
>
> - Site build now works from source distribution
> - IBM JDK test failures have been fixed
> - Automatic-Module-Name MANIFEST entry has been added for Java 9
> compatibility
>
> Commons Lang 3.6 R3 is available for review here:
>  https://dist.apache.org/repos/dist/dev/commons/lang (svn revision 19928)
>
> The tag is here:
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=
> e454e79463ffbbd9114db43019dd211debbcc105
>
> Commit ID the tag points at:
>  360198dfb6a2d68f1702f616dfacee34ae0541bb
>
> Maven Artifacts:
>  https://repository.apache.org/content/repositories/orgapachecommons-1250
>
> These are the Maven artifacts and their hashes:
>
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar
> (SHA1: c8adadb6c0b56c73f2cc2b4c77a09bfe34ec3a66)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar.asc
> (SHA1: 46347c179ca9246d146d653bdc7363bda6f17d44)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom.asc
> (SHA1: 1309d4f3dd41a01ff9dd1f3c1a6eee10dad1ef77)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom
> (SHA1: 0fb4499188c94c63b3cba44f12481e193708c4a8)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar.asc
> (SHA1: e67e7d44751f1e346c2fda496193cbe251cfe098)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar.asc
> (SHA1: 6b19fa12d319ced69c0f8a27001569514711f9dc)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar
> (SHA1: f89c1df082d6f67cb7c956715c56d7e7a0508d0a)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar
> (SHA1: e58ba08b01d37a023746f0987dcd910036a63021)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar.asc
> (SHA1: af050e8c29a801a5d6783268c56230b814f56240)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> test-sources.jar.asc
> (SHA1: 71e4c11efb9e3b2eff402ba4648d21822fb8da4a)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-test-sources.jar
> (SHA1: 04a0fc8293d4ed64a54dcc9ba5f996776a4657ea)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar
> (SHA1: 87993a16c14a251062e3fe860fa53b5ef5304a0f)
>
> I have tested this with JDK 7, JDK 8 and JDK 9 EA b172 using Maven 3.5.0.
>
> Details of changes since 3.5 are in the release notes:
>https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE-NOTES.txt
>http://home.apache.org/~britter/commons/lang/LANG_3_6_
> RC3/changes-report.html
>
> Site:
>  http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3
>  (note some *relative* links are broken and the 3.6 directories are
>  not yet created - these will be OK once the site is deployed)
>
> Clirr Report (compared to 3.5):
>http://home.apache.org/~britter/commons/lang/LANG_3_6_
> RC3/clirr-report.html
>
> RAT Report:
>http://home.apache.org/~britter/commons/lang/LANG_3_6_
> RC3/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,
> i.e. sometime after 11:00 CEST (UTC+2) 11-June 2017
>
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
>
> Thanks!
> Benedikt
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: 

Re: [VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Rob Tompkins]

> On Jun 8, 2017, at 8:09 AM, sebb  wrote:
> 
>> On 8 June 2017 at 01:20, Gary Gregory  wrote:
>> The ASC does not seem to have a public key.:
>> 
>> gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
> 
> That is not the recommended way to check a sig; you also need the target file
> 
> $ gpg --verify downloaded_file.asc downloaded_file

Indeed, but if you don't specify it looks in the current directory for the 
file. 

> 
>> gpg: assuming signed data in 'commons-fileupload-1.3.3-source-release.zip'
> 
> Note that gpg is assuming where to find the data.
> 
>> gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA key
>> ID 7188601C
>> *gpg: Can't check signature: No public key*
> 
> However if the .asc file was not detached, gpg would not check the target 
> file.
> 
> https://www.apache.org/info/verification.html#specify_both
> 
>> 
>> Also, the file naming should be consistent,
>> https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has both
>> "source-release" and "src". Not sure how you can end up with the
>> differences beyond just the file extension.
>> 
>> Gary
>> 
>> 
>>> On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins  wrote:
>>> 
>>> Hello all,
>>> 
>>> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from RC5).
>>> 
>>> Tag name:
>>>   commons-fileupload-1.3.3-RC5 (signature can be checked from git using
>>> 'git tag -v')
>>> 
>>> Tag URL:
>>>   https://git-wip-us.apache.org/repos/asf?p=commons-
>>> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
>>> 
>>> Commit ID the tag points at:
>>>   dd2238b1671644cfead0e87c24a8ac61b4039084
>>> 
>>> Site:
>>>   http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
>>> 
>>> Distribution files (committed at revision 19901):
>>>   https://dist.apache.org/repos/dist/dev/commons/fileupload/
>>> 
>>> Distribution files hashes (SHA1):
>>>   commons-fileupload-1.3.3-bin.tar.gz
>>>   (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
>>>   commons-fileupload-1.3.3-bin.zip
>>>   (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
>>>   commons-fileupload-1.3.3-src.tar.gz
>>>   (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
>>>   commons-fileupload-1.3.3-src.zip
>>>   (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
>>> 
>>> These are the Maven artifacts and their hashes:
>>>   commons-fileupload-1.3.3-javadoc.jar
>>>   (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
>>>   commons-fileupload-1.3.3-sources.jar
>>>   (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
>>>   commons-fileupload-1.3.3-test-sources.jar
>>>   (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
>>>   commons-fileupload-1.3.3-tests.jar
>>>   (SHA1: 20510147958fc759582e6ede789ccf31d056b232)
>>>   commons-fileupload-1.3.3.jar
>>>   (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
>>>   commons-fileupload-1.3.3.pom
>>>   (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
>>> 
>>> KEYS file to check signatures:
>>>   http://www.apache.org/dist/commons/KEYS
>>> 
>>> Maven artifacts:
>>>   https://repository.apache.org/content/repositories/
>>> orgapachecommons-1249
>>> 
>>> Please select one of the following options[1]:
>>>  [ ] +1 Release it.
>>>  [ ] +0 Go ahead; I don't care.
>>>  [ ] -0 There are a few minor glitches: ...
>>>  [ ] -1 No, do not release it because ...
>>> 
>>> This vote will be open at least 72 hours, i.e. until
>>> 2017-06-09T19:00:00Z
>>> (this is UTC time).
>>> 
>>> 
>>> Cheers,
>>> -Rob
>>> 
>>> [1] http://apache.org/foundation/voting.html
>>> -
>>> 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
> 

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

Re: [VOTE] Release Commons Fileupload 1.3.3 based on RC5

[sebb]

On 8 June 2017 at 01:20, Gary Gregory  wrote:
> The ASC does not seem to have a public key.:
>
> gpg --verify commons-fileupload-1.3.3-source-release.zip.asc

That is not the recommended way to check a sig; you also need the target file

$ gpg --verify downloaded_file.asc downloaded_file

> gpg: assuming signed data in 'commons-fileupload-1.3.3-source-release.zip'

Note that gpg is assuming where to find the data.

> gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA key
> ID 7188601C
> *gpg: Can't check signature: No public key*

However if the .asc file was not detached, gpg would not check the target file.

https://www.apache.org/info/verification.html#specify_both

>
> Also, the file naming should be consistent,
> https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has both
> "source-release" and "src". Not sure how you can end up with the
> differences beyond just the file extension.
>
> Gary
>
>
> On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins  wrote:
>
>> Hello all,
>>
>> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from RC5).
>>
>> Tag name:
>>commons-fileupload-1.3.3-RC5 (signature can be checked from git using
>> 'git tag -v')
>>
>> Tag URL:
>>https://git-wip-us.apache.org/repos/asf?p=commons-
>> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
>>
>> Commit ID the tag points at:
>>dd2238b1671644cfead0e87c24a8ac61b4039084
>>
>> Site:
>>http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
>>
>> Distribution files (committed at revision 19901):
>>https://dist.apache.org/repos/dist/dev/commons/fileupload/
>>
>> Distribution files hashes (SHA1):
>>commons-fileupload-1.3.3-bin.tar.gz
>>(SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
>>commons-fileupload-1.3.3-bin.zip
>>(SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
>>commons-fileupload-1.3.3-src.tar.gz
>>(SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
>>commons-fileupload-1.3.3-src.zip
>>(SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
>>
>> These are the Maven artifacts and their hashes:
>>commons-fileupload-1.3.3-javadoc.jar
>>(SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
>>commons-fileupload-1.3.3-sources.jar
>>(SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
>>commons-fileupload-1.3.3-test-sources.jar
>>(SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
>>commons-fileupload-1.3.3-tests.jar
>>(SHA1: 20510147958fc759582e6ede789ccf31d056b232)
>>commons-fileupload-1.3.3.jar
>>(SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
>>commons-fileupload-1.3.3.pom
>>(SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
>>
>> KEYS file to check signatures:
>>http://www.apache.org/dist/commons/KEYS
>>
>> Maven artifacts:
>>https://repository.apache.org/content/repositories/
>> orgapachecommons-1249
>>
>> Please select one of the following options[1]:
>>   [ ] +1 Release it.
>>   [ ] +0 Go ahead; I don't care.
>>   [ ] -0 There are a few minor glitches: ...
>>   [ ] -1 No, do not release it because ...
>>
>> This vote will be open at least 72 hours, i.e. until
>> 2017-06-09T19:00:00Z
>> (this is UTC time).
>> 
>>
>> Cheers,
>> -Rob
>>
>> [1] http://apache.org/foundation/voting.html
>> -
>> 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

[GitHub] commons-text issue #44: [TEXT-80]: Fixed confusing StrLookup API

[chtompki]

Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/44
  
@britter  - I would have to test it out, but fair point.

It feels like we should always maintain source and binary backwards 
compatibility for minor version updates. But, if the policy is different from 
that feeling, then I'm not opposed to the changes.

@garydgregory - What is the policy on source incompatible changes in minor 
version updates?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-text issue #44: [TEXT-80]: Fixed confusing StrLookup API

[britter]

Github user britter commented on the issue:

https://github.com/apache/commons-text/pull/44
  
@chtompki this indicates a source incompatible release. Binary compatible 
means that you can swap out the 1.1 jar with the 1.2 jar without a recompile. 
Would that work?

I can't recall our policy for source incompatible changes. But I think for 
example adding new methods to interfaces has been okay in the past. This is 
also source incompatible (recompilation fails) but binary compatible (swapping 
out one jar with another works).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-text issue #44: [TEXT-80]: Fixed confusing StrLookup API

[chtompki]

Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/44
  
@britter if I declare a class
```java
package com.rt;

import org.apache.commons.text.StrLookup;

public class TextTester extends StrLookup {

public String lookup(String key) {
return null;
}

}
```
on commons-text:1.1, and up-version into these changes, I get compiler 
errors. To me, that implies that we must do a major version release to 
accommodate them.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [CANCEL][VOTE] Release Commons Fileupload 1.3.3 based on RC5

[Rob Tompkins]

> On Jun 8, 2017, at 5:46 AM, sebb  wrote:
> 
> On 8 June 2017 at 01:36, Rob Tompkins  > wrote:
>> 
>> 
>>> On Jun 7, 2017, at 8:31 PM, Gary Gregory  wrote:
>>> 
 On Wed, Jun 7, 2017 at 5:30 PM, Gary Gregory  
 wrote:
 
 
 
> On Wed, Jun 7, 2017 at 5:27 PM, Rob Tompkins  wrote:
> 
> 
> 
>> On Jun 7, 2017, at 8:20 PM, Gary Gregory 
> wrote:
>> 
>> The ASC does not seem to have a public key.:
>> 
>> gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
>> gpg: assuming signed data in 'commons-fileupload-1.3.3-sour
> ce-release.zip'
>> gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA
> key
>> ID 7188601C
>> *gpg: Can't check signature: No public key*
>> 
>> 
> 
> Curious. I'll re-roll.
> 
 
>>> I wonder if this VOTE should be canceled or if properly signing the files
>>> can be done "in-line" to this VOTE?
>> 
>> Indeed I was wondering if I re-built from the tag if that would warrant an 
>> RC6.
> 
> I'm not sure I understand why the code needs to be rebuilt if the only
> problem is that the public signing key is not in KEYS.
> 
> Surely you just need to ensure that the public key is added to the KEYS file?
> 
> Or am I missing something here?

I think I missed pushing the src.zip artifacts properly to svn.

Gary, can you try again?

Thanks,
-Rob

> 
>>> 
>>> Gary
>>> 
>>> 
 Just FYI, I re-imported http://www.apache.org/dist/commons/KEYS. Just in
 case. Didn't help.
 
 Gary
 
 
> 
>> Also, the file naming should be consistent,
>> https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has
> both
>> "source-release" and "src". Not sure how you can end up with the
>> differences beyond just the file extension.
>> 
>> Gary
>> 
>> 
>>> On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins 
> wrote:
>>> 
>>> Hello all,
>>> 
>>> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from
> RC5).
>>> 
>>> Tag name:
>>> commons-fileupload-1.3.3-RC5 (signature can be checked from git using
>>> 'git tag -v')
>>> 
>>> Tag URL:
>>> https://git-wip-us.apache.org/repos/asf?p=commons-
>>> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
>>> 
>>> Commit ID the tag points at:
>>> dd2238b1671644cfead0e87c24a8ac61b4039084
>>> 
>>> Site:
>>> http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
>>> 
>>> Distribution files (committed at revision 19901):
>>> https://dist.apache.org/repos/dist/dev/commons/fileupload/
>>> 
>>> Distribution files hashes (SHA1):
>>> commons-fileupload-1.3.3-bin.tar.gz
>>> (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
>>> commons-fileupload-1.3.3-bin.zip
>>> (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
>>> commons-fileupload-1.3.3-src.tar.gz
>>> (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
>>> commons-fileupload-1.3.3-src.zip
>>> (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
>>> 
>>> These are the Maven artifacts and their hashes:
>>> commons-fileupload-1.3.3-javadoc.jar
>>> (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
>>> commons-fileupload-1.3.3-sources.jar
>>> (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
>>> commons-fileupload-1.3.3-test-sources.jar
>>> (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
>>> commons-fileupload-1.3.3-tests.jar
>>> (SHA1: 20510147958fc759582e6ede789ccf31d056b232)
>>> commons-fileupload-1.3.3.jar
>>> (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
>>> commons-fileupload-1.3.3.pom
>>> (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
>>> 
>>> KEYS file to check signatures:
>>> http://www.apache.org/dist/commons/KEYS
>>> 
>>> Maven artifacts:
>>> https://repository.apache.org/content/repositories/
>>> orgapachecommons-1249
>>> 
>>> Please select one of the following options[1]:
>>> [ ] +1 Release it.
>>> [ ] +0 Go ahead; I don't care.
>>> [ ] -0 There are a few minor glitches: ...
>>> [ ] -1 No, do not release it because ...
>>> 
>>> This vote will be open at least 72 hours, i.e. until
>>> 2017-06-09T19:00:00Z
>>> (this is UTC time).
>>> 
>>> 
>>> Cheers,
>>> -Rob
>>> 
>>> [1] http://apache.org/foundation/voting.html
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 
> 
> -
> To unsubscribe, e-mail: 

Re: NUMBERS-40: Review exception usage in package "o.a.c.numbers.gamma"

[Gilles]

Hi.

On Wed, 7 Jun 2017 17:00:46 -0500, Tharaka De Silva wrote:

Hello everyone,

I am new to the ASF community


Welcome.


and decided to grab something easy to
attempt. I decided to take a shot at:
https://issues.apache.org/jira/browse/NUMBERS-40.


Easy to change is not always similar to easy to decide what
changes to perform. ;-)



The rationale of implementing this design would be this:
GammaException is currently a subclass of IllegalArgumentException 
but the
reason for an argument to be invalid would be because it is 
arithmetically
impossible hence why it should be an ArithmeticException rather than 
a

IllegalArgumentException.


In quite a few cases, it is actually _not_ "arithmetically impossible",
it is a limitation of the implementation.

The JIRA report asks whether it is possible to use a single exception
type (currently "GammaException") for all programming errors, given 
that

the base class of all errors _cannot_ be "ArithmeticException" (as the
above explains).

As an aside, in the unit tests, the use of the exception's base (JDK)
class in the "expected" clause is intentional as the unit tests are
mainly supposed to  check the public API (and "GammaException" is
package-private).
In "Commons Numbers", the idea would be to have a most simple exception
handling (throwing only JDK exceptions) since it is expected (TBC) that
all of them result from incorrect usage or bugs in the library.


Regards,
Gilles



What do you guys think?



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

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Bruno P. Kinoshita]

[ X ] +1 Release these artifacts

Build passing for Oracle JDK 7, Oracle JDK 8, and IBM JDK 8.

Thanks a lot for preparing the release,
Bruno


From: Benedikt Ritter 
To: Commons Developers List  
Sent: Thursday, 8 June 2017 8:48 PM
Subject: [VOTE] Release Apache Commons Lang 3.6 based on RC3



Hello,


we have fixed quite a few bugs and added some nice new features since Commons 
Lang 3.5 was released, so I would like to release Commons Lang 3.6 based on RC3.

The following issues have been fixed since RC2:


- Site build now works from source distribution

- IBM JDK test failures have been fixed

- Automatic-Module-Name MANIFEST entry has been added for Java 9 compatibility


Commons Lang 3.6 R3 is available for review here:

https://dist.apache.org/repos/dist/dev/commons/lang (svn revision 19928)


The tag is here:

https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=e454e79463ffbbd9114db43019dd211debbcc105


Commit ID the tag points at:

360198dfb6a2d68f1702f616dfacee34ae0541bb


Maven Artifacts:

https://repository.apache.org/content/repositories/orgapachecommons-1250


These are the Maven artifacts and their hashes:


/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar

(SHA1: c8adadb6c0b56c73f2cc2b4c77a09bfe34ec3a66)

/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar.asc

(SHA1: 46347c179ca9246d146d653bdc7363bda6f17d44)

/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom.asc

(SHA1: 1309d4f3dd41a01ff9dd1f3c1a6eee10dad1ef77)

/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom

(SHA1: 0fb4499188c94c63b3cba44f12481e193708c4a8)

/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar.asc

(SHA1: e67e7d44751f1e346c2fda496193cbe251cfe098)

/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar.asc

(SHA1: 6b19fa12d319ced69c0f8a27001569514711f9dc)

/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar

(SHA1: f89c1df082d6f67cb7c956715c56d7e7a0508d0a)

/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar

(SHA1: e58ba08b01d37a023746f0987dcd910036a63021)

/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar.asc

(SHA1: af050e8c29a801a5d6783268c56230b814f56240)

/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-test-sources.jar.asc

(SHA1: 71e4c11efb9e3b2eff402ba4648d21822fb8da4a)

/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-test-sources.jar

(SHA1: 04a0fc8293d4ed64a54dcc9ba5f996776a4657ea)

/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar

(SHA1: 87993a16c14a251062e3fe860fa53b5ef5304a0f)


I have tested this with JDK 7, JDK 8 and JDK 9 EA b172 using Maven 3.5.0.


Details of changes since 3.5 are in the release notes:

  https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE-NOTES.txt

  http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3/changes-report.html


Site:

http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3

(note some *relative* links are broken and the 3.6 directories are

not yet created - these will be OK once the site is deployed)


Clirr Report (compared to 3.5):

  http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3/clirr-report.html


RAT Report:

  http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3/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,

i.e. sometime after 11:00 CEST (UTC+2) 11-June 2017


[ ] +1 Release these artifacts

[ ] +0 OK, but...

[ ] -0 OK, but really should fix...

[ ] -1 I oppose this release because...


Thanks!

Benedikt

-

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: [CANCEL][VOTE] Release Commons Fileupload 1.3.3 based on RC5

[sebb]

On 8 June 2017 at 01:36, Rob Tompkins  wrote:
>
>
>> On Jun 7, 2017, at 8:31 PM, Gary Gregory  wrote:
>>
>>> On Wed, Jun 7, 2017 at 5:30 PM, Gary Gregory  wrote:
>>>
>>>
>>>
 On Wed, Jun 7, 2017 at 5:27 PM, Rob Tompkins  wrote:



> On Jun 7, 2017, at 8:20 PM, Gary Gregory 
 wrote:
>
> The ASC does not seem to have a public key.:
>
> gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
> gpg: assuming signed data in 'commons-fileupload-1.3.3-sour
 ce-release.zip'
> gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA
 key
> ID 7188601C
> *gpg: Can't check signature: No public key*
>
>

 Curious. I'll re-roll.

>>>
>> I wonder if this VOTE should be canceled or if properly signing the files
>> can be done "in-line" to this VOTE?
>
> Indeed I was wondering if I re-built from the tag if that would warrant an 
> RC6.

I'm not sure I understand why the code needs to be rebuilt if the only
problem is that the public signing key is not in KEYS.

Surely you just need to ensure that the public key is added to the KEYS file?

Or am I missing something here?

>>
>> Gary
>>
>>
>>> Just FYI, I re-imported http://www.apache.org/dist/commons/KEYS. Just in
>>> case. Didn't help.
>>>
>>> Gary
>>>
>>>

> Also, the file naming should be consistent,
> https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has
 both
> "source-release" and "src". Not sure how you can end up with the
> differences beyond just the file extension.
>
> Gary
>
>
>> On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins 
 wrote:
>>
>> Hello all,
>>
>> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from
 RC5).
>>
>> Tag name:
>>  commons-fileupload-1.3.3-RC5 (signature can be checked from git using
>> 'git tag -v')
>>
>> Tag URL:
>>  https://git-wip-us.apache.org/repos/asf?p=commons-
>> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084
>>
>> Commit ID the tag points at:
>>  dd2238b1671644cfead0e87c24a8ac61b4039084
>>
>> Site:
>>  http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5
>>
>> Distribution files (committed at revision 19901):
>>  https://dist.apache.org/repos/dist/dev/commons/fileupload/
>>
>> Distribution files hashes (SHA1):
>>  commons-fileupload-1.3.3-bin.tar.gz
>>  (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa)
>>  commons-fileupload-1.3.3-bin.zip
>>  (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa)
>>  commons-fileupload-1.3.3-src.tar.gz
>>  (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73)
>>  commons-fileupload-1.3.3-src.zip
>>  (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52)
>>
>> These are the Maven artifacts and their hashes:
>>  commons-fileupload-1.3.3-javadoc.jar
>>  (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99)
>>  commons-fileupload-1.3.3-sources.jar
>>  (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673)
>>  commons-fileupload-1.3.3-test-sources.jar
>>  (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708)
>>  commons-fileupload-1.3.3-tests.jar
>>  (SHA1: 20510147958fc759582e6ede789ccf31d056b232)
>>  commons-fileupload-1.3.3.jar
>>  (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40)
>>  commons-fileupload-1.3.3.pom
>>  (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c)
>>
>> KEYS file to check signatures:
>>  http://www.apache.org/dist/commons/KEYS
>>
>> Maven artifacts:
>>  https://repository.apache.org/content/repositories/
>> orgapachecommons-1249
>>
>> Please select one of the following options[1]:
>> [ ] +1 Release it.
>> [ ] +0 Go ahead; I don't care.
>> [ ] -0 There are a few minor glitches: ...
>> [ ] -1 No, do not release it because ...
>>
>> This vote will be open at least 72 hours, i.e. until
>> 2017-06-09T19:00:00Z
>> (this is UTC time).
>> 
>>
>> Cheers,
>> -Rob
>>
>> [1] http://apache.org/foundation/voting.html
>> -
>> 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


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

[VOTE] Release Apache Commons Lang 3.6 based on RC3

[Benedikt Ritter]

Hello,

we have fixed quite a few bugs and added some nice new features since Commons 
Lang 3.5 was released, so I would like to release Commons Lang 3.6 based on RC3.
The following issues have been fixed since RC2:

- Site build now works from source distribution
- IBM JDK test failures have been fixed
- Automatic-Module-Name MANIFEST entry has been added for Java 9 compatibility

Commons Lang 3.6 R3 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/lang (svn revision 19928)

The tag is here:
https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=e454e79463ffbbd9114db43019dd211debbcc105

Commit ID the tag points at:
 360198dfb6a2d68f1702f616dfacee34ae0541bb

Maven Artifacts:
 https://repository.apache.org/content/repositories/orgapachecommons-1250

These are the Maven artifacts and their hashes:

/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar
(SHA1: c8adadb6c0b56c73f2cc2b4c77a09bfe34ec3a66)
/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar.asc
(SHA1: 46347c179ca9246d146d653bdc7363bda6f17d44)
/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom.asc
(SHA1: 1309d4f3dd41a01ff9dd1f3c1a6eee10dad1ef77)
/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom
(SHA1: 0fb4499188c94c63b3cba44f12481e193708c4a8)
/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar.asc
(SHA1: e67e7d44751f1e346c2fda496193cbe251cfe098)
/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar.asc
(SHA1: 6b19fa12d319ced69c0f8a27001569514711f9dc)
/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar
(SHA1: f89c1df082d6f67cb7c956715c56d7e7a0508d0a)
/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar
(SHA1: e58ba08b01d37a023746f0987dcd910036a63021)
/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar.asc
(SHA1: af050e8c29a801a5d6783268c56230b814f56240)
/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-test-sources.jar.asc
(SHA1: 71e4c11efb9e3b2eff402ba4648d21822fb8da4a)
/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-test-sources.jar
(SHA1: 04a0fc8293d4ed64a54dcc9ba5f996776a4657ea)
/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar
(SHA1: 87993a16c14a251062e3fe860fa53b5ef5304a0f)

I have tested this with JDK 7, JDK 8 and JDK 9 EA b172 using Maven 3.5.0.

Details of changes since 3.5 are in the release notes:
   https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE-NOTES.txt
   http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3/changes-report.html

Site:
 http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3
 (note some *relative* links are broken and the 3.6 directories are
 not yet created - these will be OK once the site is deployed)

Clirr Report (compared to 3.5):
   http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3/clirr-report.html

RAT Report:
   http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3/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,
i.e. sometime after 11:00 CEST (UTC+2) 11-June 2017

 [ ] +1 Release these artifacts
 [ ] +0 OK, but...
 [ ] -0 OK, but really should fix...
 [ ] -1 I oppose this release because...

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

[GitHub] commons-text issue #44: [TEXT-80]: Fixed confusing StrLookup API

[britter]

Github user britter commented on the issue:

https://github.com/apache/commons-text/pull/44
  
@ameyjadiye the best would be to rebase your branch against master an dann 
do a force push. You can do it like this (if you have configured this 
repository as remote with name upstream):

```shell
git checkout master
git fetch upstream
git merge upstream/master
git checkout TEXT-80
git rebase master
git push -f
```

This will bring your branch up to date with master and trigger a new CI 
build.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-text issue #44: [TEXT-80]: Fixed confusing StrLookup API

[ameyjadiye]

Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/44
  
Hi @britter, there is no issue even in checkstyle with my changes,  above 
Travis build failed because there was some trailing space issue in master and 
which you have already fixed. merging this will pass everything clean *OR* you 
want me to do some dummy commit so Travis will trigger again and clear  error 
on this PR ? I don't think that's needed though.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [LANG] Add Automatic-Module-Name MANIFEST entry

[Benedikt Ritter]

Hi,

> Am 07.06.2017 um 15:09 schrieb Jörg Schaible :
> 
> Stefan Bodewig wrote:
> 
>> On 2017-06-07, Benedikt Ritter wrote:
>> 
>>> here [1] is my proposal on how to add the Automatic-Module-Name entry
>>> to MANIFEST. This just duplicates the maven-jar-plugin configuration
>>> from parent pom. I don’t want to wait much longer to release
>>> 3.6. After we have implemented a more general solution in parent pom,
>>> we can revert this fix.
>> 
>> I've done something similar to Compress already. As Compress has been
>> overriding the jar-plugin configuration already (in order to add a
>> main-class) there's been no other option anyway.
>> 
>> I'm afraid Compress is not the only component that overrides the
>> parent's jar config and thus will require copying the change manually
>> even if you happen to find a solution for parent.
> 
> You don't have to overwrite the jar's parent config. Simply append/overwrite 
> the existing entries:
> 
>  
>
>  
>org.apache.commons.compress.archivers.Lister Class>
>  
>
>  
> 
> That's it ;-)

Awesome, I could use this trick to add the Automatic-Module-Name entry without 
having to duplicate the whole maven-jar-plugin configuration!

Thank you
Benedikt

> 
> Cheers,
> Jörg
> 
> 
> -
> 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

[GitHub] commons-text issue #44: [TEXT-80]: Fixed confusing StrLookup API

[britter]

Github user britter commented on the issue:

https://github.com/apache/commons-text/pull/44
  
@chtompki did you run chirr manually? Because it was checkstyle which 
caused the Travis build to fail (trailing white spaces). I think this change 
should not break BC. @ameyjadiye can you please fix the checkstyle errors and 
push again?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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