Re: OSGi Version at Package Level

[Bertrand Delacretaz]

Hi,

On Wed, Jun 7, 2017 at 2:10 AM, Jörg Schaible  wrote:
> ...maybe you have missed the discussion for
> https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a
> PR that introduces individual versions at package level for a component

That's standard practice for OSGi bundles.

The https://github.com/apache/commons-compress/pull/26 changes look
suboptimal because they set the same initial version for each exported
package, but that's correct as a way to start doing that.

The "baseline" goal of the Apache Felix maven-bundle-plugin can then
be used to automatically recommend changes to those version numbers to
implement semantic versioning *at the java package level* which is the
way OSGi handles this.

We're using this extensively in Apache Sling, where we release a large
number of bundles each with their own package-level version numbers
which evolve independently from the bundle version. It works well once
it's setup, which is what that pull/26 does AFAICS.

Here's example output from that plugin building [1] after adding a
method to a class in the o.a.s.distribution package:

[INFO] Baseline Report - Generated by Apache Felix Maven Bundle Plugin
on 2017-06-07T08:54Z based on Bnd - see http://www.aqute.biz/Bnd/Bnd
[INFO] Comparing bundle org.apache.sling.distribution.api version
0.3.1-SNAPSHOT to version 0.3.0
[INFO]
[INFO]   PACKAGE_NAME   DELTA
CUR_VERBASE_VER   REC_VERWARNINGS
[INFO] = == ==
== == == ==
[INFO] * org.apache.sling.distribution  minor
0.3.0  0.3.0  0.4.0  Version increase required
[INFO]  < interface org.apache.sling.distribution.Distributor
[INFO]  + method doNothing()
[INFO]  + access abstract
[INFO] 
---
[INFO]   org.apache.sling.distribution.eventunchanged
0.1.1  0.1.1  0.1.1  -
[INFO] 
---
[INFO]   org.apache.sling.distribution.transportunchanged
0.1.0  0.1.0  0.1.0  -
[INFO] 
---
[ERROR] org.apache.sling.distribution: Version increase required;
detected 0.3.0, suggested 0.4.0
[INFO] Baseline analysis complete, 1 error(s), 0 warning(s)

HTH,
-Bertrand

[1] 
https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/distribution/api

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

[GitHub] commons-compress issue #26: COMPRESS-399 OSGI package versions are overly pe...

[bodewig]

Github user bodewig commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
Sorry, I'm currently swamped and won't find time to look into this for the 
coming days. @sesuncedu there is a discussion going on on the dev mailing list 
that you may want to join -> 
https://lists.apache.org/thread.html/4a205ffad0ae0886113e76f358a6fbe59dfdf113f194c5fa687cdd69@%3Cdev.commons.apache.org%3E


---
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: OSGi Version at Package Level

[Gary Gregory]

On Tue, Jun 6, 2017 at 5:10 PM, Jörg Schaible  wrote:

> Hi,
>
> maybe you have missed the discussion for
> https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a
> PR that introduces individual versions at package level for a component.
>
> Actually I can understand the reasoning from a logical point if view, but
> it
> fails for me completely from the practical side. Do we really want
> different
> versions inside a single component? Can we even guarantee binary
> compatibility to such an extent? Do we want such a micro-management for
> each
> release?
>
> IMHO it does not make sense, our release process is enervating enough.
> Until
> now we provide one version for each release that is also valid for OSGi. I
> have not too much experience with OSGi myself, but when I look into the
> Eclipse ecosystem then I can see that a complete bunch of plugins is
> released together as one version - I am not aware that they do such package
> based version management. And - AFACIS - it is also possible to declare
> valid ranges for OSGi dependencies. And we ensure with our release policy
> for major versions (new package name) that no dependency can upgraded by
> pure chance to a major incompatible version.
>
> I won't put a veto on the commit of this PR, but actually I am not
> interesting in supporting such a scenario for our components.
>
> Your opinions?
>

It sounds like a maintenance nightmare.

Is there at least a Maven plugin to help like Clirr and japicmp, but for
OSGi?

Gary


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

OSGi Version at Package Level

[Jörg Schaible]

Hi,

maybe you have missed the discussion for 
https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a 
PR that introduces individual versions at package level for a component.

Actually I can understand the reasoning from a logical point if view, but it 
fails for me completely from the practical side. Do we really want different 
versions inside a single component? Can we even guarantee binary 
compatibility to such an extent? Do we want such a micro-management for each 
release?

IMHO it does not make sense, our release process is enervating enough. Until 
now we provide one version for each release that is also valid for OSGi. I 
have not too much experience with OSGi myself, but when I look into the 
Eclipse ecosystem then I can see that a complete bunch of plugins is 
released together as one version - I am not aware that they do such package 
based version management. And - AFACIS - it is also possible to declare 
valid ranges for OSGi dependencies. And we ensure with our release policy 
for major versions (new package name) that no dependency can upgraded by 
pure chance to a major incompatible version.

I won't put a veto on the commit of this PR, but actually I am not 
interesting in supporting such a scenario for our components.

Your opinions?

Cheers,
Jörg


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

Re: [NUMBERS] Proposal for refactoring and extension of Gamma functions.

[Gilles]

Hi Amey.

On Wed, 7 Jun 2017 01:15:01 +0530, Amey Jadiye wrote:

Hi,

Gamma class is written keeping in mind that it should handle fair 
situation

(if n < 20) it computes with normal gamma function else it uses
LanczosApproximation
for higher numbers, for now I think we should keep it behaviour as it 
is
and do just code segrigation, by segregation of there functionalities 
we
are making it switchable so Gamma class by optional providing 
constructor
args of Lanzoz, Stinling or Spouge's algo, same thing we have to do 
in

Math's Gamma distribution.

Ex.
Gamma g = Gamma(Algo.LANCZOS));


Just from the look of it, it is difficult to figure out whether
alternative algorithms are useful when numbers are represented
as 64-bits "double".

If you are willing to go that route, you should provide code that
shows the advantages (speed and/or precision).

Now, if we want to support an arbirary precision number type[1],
then the alternate algorithms that can provide accuracy below
~1e-16 would certainly be worth considering.[2]


I'd like other people from group chime in discussion.



Regards,
Gilles

[1] See the "Dfp" class in CM's "o.a.c.math4.dfp" package.
[2] But IMO this should be postponed to after 1.0 since there
is perhaps a need of a general discussion about designing
high-precision algorithms (and whether there are volunteers
to develop and support them in the long term).
I may be wrong, but somehow I have the intuition that people
requiring those functionalities might not be using Java...



Regards,
Amey

On Tue, Jun 6, 2017 at 3:31 AM, Gilles  
wrote:



On Tue, 6 Jun 2017 01:14:38 +0530, Amey Jadiye wrote:


Hi All,

Coming from discussion happened here
https://issues.apache.org/jira/browse/NUMBERS-38

As Gamma is nothing but advanced factorial function gamma(n)=(n-1)! 
with

advantages like we can have factorial of whole numbers as well as
factional. Now as [Gamma functions (
https://en.wikipedia.org/wiki/Gamma_function ) which is having 
general
formula {{Gamma( x ) = integral( t^(x-1) e^(-t), t = 0 .. 
infinity)}} is a

plane old base function however Lanczos approximation / Stirling's
approximation /Spouge's Approximation  *is a* gamma function so 
they

should
be extend Gamma.

Exact algorithm and formulas here :
 - Lanczo's Approximation -
https://en.wikipedia.org/wiki/Lanczos_approximation
 - Stirling's Approximation  -
https://en.wikipedia.org/wiki/Stirling%27s_approximation
 - Spouge's Approximation -
https://en.wikipedia.org/wiki/Spouge%27s_approximation

Why to refactor code is because basic gamma function computes not 
so
accurate/precision values so someone who need quick computation 
without
precision can choose it, while someone who need precision overs 
cost of
performance (Lanczos approximation is accurate so its slow takes 
more cpu

cycle) can choose which algorithm they want.

for some scientific application all values should be computed with 
great
precision, with out Gamma class no choice is given for choosing 
which

algorithm user want.

I'm proposing to create something like:

Gamma gammaFun = new Gamma(); gammaFun.value( x );
Gamma gammaFun = new LanczosGamma(); gammaFun.value( x );
Gamma gammaFun = new StirlingsGamma(); gammaFun.value( x );
Gamma gammaFun = new SpougesGamma(); gammaFun.value( x );

Also as the class name suggestion {{LanczosApproximation}} it 
should
execute/implement full *Lanczos Algoritham* but we are just 
computing
coefficients in that class which is incorrect, so just refactoring 
is
needed which wont break any dependency of this class anywhere. 
(will

modify
code such way).

let me know your thoughts?



I've added a comment (about the multiple implementations) on the
JIRA page.

I agree that if the class currently named "LanczosApproximation" is
not what the references define as "Lanczos' approximation", it 
should

be renamed.
My preference would be to "hide" it inside the "Gamma" class, if we
can sort out how to modify the "GammaDistribution" class (in Commons
Math) accordingly.

Regards,
Gilles





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

Re: Compiler targets and Java 9

[Bernd Eckenfels]

I don't think Java 9's capabilities are relevant for the project target. We 
compile for 1.x with the help of %JAVA_1_x_HOME% or toolchains (via -Pjava1.x 
profile), but  not with -target parameter. It's easier this way as you don't 
have to worry about the bootclasspath of the compiler. This is true for 1.6 
projects compiled with 1.8 maven-Java today.

So while it is good to review prerequisite minimum versions regularly Java 9 
seems not a immediate motivation.

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Benedikt Ritter 
Sent: Tuesday, June 6, 2017 1:57:22 PM
To: Commons Developers List
Subject: Re: Compiler targets and Java 9


> Am 05.06.2017 um 16:41 schrieb Jochen Wiedmann :
>
> Hi,
>
> thanks to Rob Rompkins, and his recent work on Fileupload, it came to
> my attention that Java 9 will no longer support JVM 1.5, and lower, as
> a compiler target. [1]
>
> This means, that we will be preventing our developers from using Java
> 9, if a component is still below 1.6. (And, I'd expect that to be the
> case for quite some projects.)
>
> Now, leaving the general discussions regarding Java 9, and (in
> particular) Jigsaw, aside, I think that is something that we ought to
> consider.
>
> OTOH, it seems reasonable to expect that Java 9 adoption will be slow,
> given that it isn't upwards compatible.
>
> So, as a  compromise, I propose that we adopt the following policy:
>
> All commons proper components are expected within one year from now on
> to bump their compiler target to 1.6, or beyond, and have a release
> published with that target. That way, we know, that it works fine with
> the Java 9 compiler.

+1

Benedikt

>
> Jochen
>
>
>
>
> 1: http://openjdk.java.net/jeps/182
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> 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: [all] Should our gitignore files contain only build-related entries?

[sebb]

On 6 June 2017 at 22:09, Bernd Eckenfels  wrote:
> GIBo uses the Github profiles:
> https://github.com/github/gitignore/blob/master/Java.gitignore

At least some of those may cause problems for Compress test data ...

> https://github.com/github/gitignore/blob/master/Maven.gitignore
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Benedikt Ritter 
> Sent: Tuesday, June 6, 2017 1:50:14 PM
> To: Commons Developers List
> Subject: Re: [all] Should our gitignore files contain only build-related 
> entries?
>
> Hello Bernd,
>
>> Am 05.06.2017 um 18:47 schrieb Bernd Eckenfels :
>>
>> Are we talking about only the Maven profile or also about the Java profile. 
>> I find that one overly eager and why does it contain BlueJ IDE (only)?
>
> What are you referring to with „Maven profile“ and „Java profile“?
>
> Cheers,
> Benedikt
>
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> 
>> From: sebb 
>> Sent: Monday, June 5, 2017 5:09:18 PM
>> To: Commons Developers List
>> Subject: Re: [all] Should our gitignore files contain only build-related 
>> entries?
>>
>> On 5 June 2017 at 11:20, Benedikt Ritter  wrote:
>>> Hi,
>>>
>>> I usually only use what gibo [1] generates. I don’t put editor specific 
>>> entries into .gitignore for my personal projects. This stuff should go into 
>>> your personal gitignore. If developers don’t know about global gitignore we 
>>> should educate them instead of promoting non-sense project setups.
>>
>> +1
>>
>>> Regards,
>>> Benedikt
>>>
>>> [1] https://github.com/simonwhitaker/gibo
>>>
 Am 01.06.2017 um 19:09 schrieb Gary Gregory :

 If we do not have per component .gitignore files, then we better have clear
 instructions front and center on how to set up Git for what we expect.

 Gary

 On Wed, May 31, 2017 at 2:04 AM, Amey Jadiye  wrote:

> Hi,
>
> I think easier way to have all ignorable extensions and directories in
> .gitignore and same have to be replicated in global gitignore from all
> other Commons projects. Commons is always having short fixes and
> improvements , people tend to fork>work>PR>delete repo on local pc.
> Instructions should be in UsingGIT and CONTRIBUTING.md but not sure people
> will follow everything. Ignores already  present in .gitignore of each
> project makes everything painles.
>
> Regards,
> Amey
>
> On Sat, May 27, 2017, 7:03 PM Bruno P. Kinoshita
>  wrote:
>
>> Hi,
>>
>> [collections] recently received a pull request [1] to add VIM files to
> the
>> gitignore file. Its currently gitignore contains only a few entries for
>> Eclipse ([lang] has more entries for Eclipse).
>>
>> I remember asking something similar, and learning about the global
>> gitignore. But besides that, in the same thread, Benedikt suggested
> having
>> only build files ignored in our gitignore files [2], which I think is a
>> good idea. Our components do not follow any rule for gitignore files I
>> think. I normally check [lang] when I need to add a .gitignore to a new
>> computer, but just realized [text] and [lang] gitignore files differ
>> ([lang] has a .checkstyle file under the Eclipse ignored files).
>>
>>
>> I'm okay merging the pull request for [collections], but then we may also
>> add the remaining entries from [lang] there... except this pull request
>> adds *.swp which is missing from [lang]. So should we add it there too?
>>
>> Some days ago I used NetBeans to test a generics suppress warning message
>> [3], but we may have developers using it as main IDE too. Would it be all
>> right to merge pull requests for it too? Or for files generated by
> plug-ins
>> for Eclipse/IntelliJ/etc?
>> What about 1) leaving only files generated by our build tools, 2) add a
>> comment to the .gitignore file describing how it works with links, 3)
> add a
>> comment to
>> https://wiki.apache.org/commons/UsingGIT and/or to the CONTRIBUTING.md
>> perhaps with a sample global gitignore file?
>>
>> Cheers
>> Bruno
>>
>> [1] https://github.com/apache/commons-collections/pull/21
>> [2]
>> http://markmail.org/message/yvflc6kxgjalhldx?q=global+
> gitignore+list:org%2Eapache%2Ecommons%2Edev#query:global%
> 20gitignore%20list%3Aorg.apache.commons.dev+page:1+mid:
> ioex63sxnf6culwb+state:results
>> [3] https://github.com/apache/commons-collections/pull/17
>>
>> -
>> 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 

Re: [all] Should our gitignore files contain only build-related entries?

[Bernd Eckenfels]

GIBo uses the Github profiles:
https://github.com/github/gitignore/blob/master/Java.gitignore
https://github.com/github/gitignore/blob/master/Maven.gitignore

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Benedikt Ritter 
Sent: Tuesday, June 6, 2017 1:50:14 PM
To: Commons Developers List
Subject: Re: [all] Should our gitignore files contain only build-related 
entries?

Hello Bernd,

> Am 05.06.2017 um 18:47 schrieb Bernd Eckenfels :
>
> Are we talking about only the Maven profile or also about the Java profile. I 
> find that one overly eager and why does it contain BlueJ IDE (only)?

What are you referring to with „Maven profile“ and „Java profile“?

Cheers,
Benedikt

>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: sebb 
> Sent: Monday, June 5, 2017 5:09:18 PM
> To: Commons Developers List
> Subject: Re: [all] Should our gitignore files contain only build-related 
> entries?
>
> On 5 June 2017 at 11:20, Benedikt Ritter  wrote:
>> Hi,
>>
>> I usually only use what gibo [1] generates. I don’t put editor specific 
>> entries into .gitignore for my personal projects. This stuff should go into 
>> your personal gitignore. If developers don’t know about global gitignore we 
>> should educate them instead of promoting non-sense project setups.
>
> +1
>
>> Regards,
>> Benedikt
>>
>> [1] https://github.com/simonwhitaker/gibo
>>
>>> Am 01.06.2017 um 19:09 schrieb Gary Gregory :
>>>
>>> If we do not have per component .gitignore files, then we better have clear
>>> instructions front and center on how to set up Git for what we expect.
>>>
>>> Gary
>>>
>>> On Wed, May 31, 2017 at 2:04 AM, Amey Jadiye  wrote:
>>>
 Hi,

 I think easier way to have all ignorable extensions and directories in
 .gitignore and same have to be replicated in global gitignore from all
 other Commons projects. Commons is always having short fixes and
 improvements , people tend to fork>work>PR>delete repo on local pc.
 Instructions should be in UsingGIT and CONTRIBUTING.md but not sure people
 will follow everything. Ignores already  present in .gitignore of each
 project makes everything painles.

 Regards,
 Amey

 On Sat, May 27, 2017, 7:03 PM Bruno P. Kinoshita
  wrote:

> Hi,
>
> [collections] recently received a pull request [1] to add VIM files to
 the
> gitignore file. Its currently gitignore contains only a few entries for
> Eclipse ([lang] has more entries for Eclipse).
>
> I remember asking something similar, and learning about the global
> gitignore. But besides that, in the same thread, Benedikt suggested
 having
> only build files ignored in our gitignore files [2], which I think is a
> good idea. Our components do not follow any rule for gitignore files I
> think. I normally check [lang] when I need to add a .gitignore to a new
> computer, but just realized [text] and [lang] gitignore files differ
> ([lang] has a .checkstyle file under the Eclipse ignored files).
>
>
> I'm okay merging the pull request for [collections], but then we may also
> add the remaining entries from [lang] there... except this pull request
> adds *.swp which is missing from [lang]. So should we add it there too?
>
> Some days ago I used NetBeans to test a generics suppress warning message
> [3], but we may have developers using it as main IDE too. Would it be all
> right to merge pull requests for it too? Or for files generated by
 plug-ins
> for Eclipse/IntelliJ/etc?
> What about 1) leaving only files generated by our build tools, 2) add a
> comment to the .gitignore file describing how it works with links, 3)
 add a
> comment to
> https://wiki.apache.org/commons/UsingGIT and/or to the CONTRIBUTING.md
> perhaps with a sample global gitignore file?
>
> Cheers
> Bruno
>
> [1] https://github.com/apache/commons-collections/pull/21
> [2]
> http://markmail.org/message/yvflc6kxgjalhldx?q=global+
 gitignore+list:org%2Eapache%2Ecommons%2Edev#query:global%
 20gitignore%20list%3Aorg.apache.commons.dev+page:1+mid:
 ioex63sxnf6culwb+state:results
> [3] https://github.com/apache/commons-collections/pull/17
>
> -
> 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: [NUMBERS] Proposal for refactoring and extension of Gamma functions.

[Amey Jadiye]

Hi,

Gamma class is written keeping in mind that it should handle fair situation
(if n < 20) it computes with normal gamma function else it uses
LanczosApproximation
for higher numbers, for now I think we should keep it behaviour as it is
and do just code segrigation, by segregation of there functionalities  we
are making it switchable so Gamma class by optional providing constructor
args of Lanzoz, Stinling or Spouge's algo, same thing we have to do in
Math's Gamma distribution.

Ex.
Gamma g = Gamma(Algo.LANCZOS));

I'd like other people from group chime in discussion.

Regards,
Amey

On Tue, Jun 6, 2017 at 3:31 AM, Gilles  wrote:

> On Tue, 6 Jun 2017 01:14:38 +0530, Amey Jadiye wrote:
>
>> Hi All,
>>
>> Coming from discussion happened here
>> https://issues.apache.org/jira/browse/NUMBERS-38
>>
>> As Gamma is nothing but advanced factorial function gamma(n)=(n-1)! with
>> advantages like we can have factorial of whole numbers as well as
>> factional. Now as [Gamma functions (
>> https://en.wikipedia.org/wiki/Gamma_function ) which is having general
>> formula {{Gamma( x ) = integral( t^(x-1) e^(-t), t = 0 .. infinity)}} is a
>> plane old base function however Lanczos approximation / Stirling's
>> approximation /Spouge's Approximation  *is a* gamma function so they
>> should
>> be extend Gamma.
>>
>> Exact algorithm and formulas here :
>>  - Lanczo's Approximation -
>> https://en.wikipedia.org/wiki/Lanczos_approximation
>>  - Stirling's Approximation  -
>> https://en.wikipedia.org/wiki/Stirling%27s_approximation
>>  - Spouge's Approximation -
>> https://en.wikipedia.org/wiki/Spouge%27s_approximation
>>
>> Why to refactor code is because basic gamma function computes not so
>> accurate/precision values so someone who need quick computation without
>> precision can choose it, while someone who need precision overs cost of
>> performance (Lanczos approximation is accurate so its slow takes more cpu
>> cycle) can choose which algorithm they want.
>>
>> for some scientific application all values should be computed with great
>> precision, with out Gamma class no choice is given for choosing which
>> algorithm user want.
>>
>> I'm proposing to create something like:
>>
>> Gamma gammaFun = new Gamma(); gammaFun.value( x );
>> Gamma gammaFun = new LanczosGamma(); gammaFun.value( x );
>> Gamma gammaFun = new StirlingsGamma(); gammaFun.value( x );
>> Gamma gammaFun = new SpougesGamma(); gammaFun.value( x );
>>
>> Also as the class name suggestion {{LanczosApproximation}} it should
>> execute/implement full *Lanczos Algoritham* but we are just computing
>> coefficients in that class which is incorrect, so just refactoring is
>> needed which wont break any dependency of this class anywhere. (will
>> modify
>> code such way).
>>
>> let me know your thoughts?
>>
>>
> I've added a comment (about the multiple implementations) on the
> JIRA page.
>
> I agree that if the class currently named "LanczosApproximation" is
> not what the references define as "Lanczos' approximation", it should
> be renamed.
> My preference would be to "hide" it inside the "Gamma" class, if we
> can sort out how to modify the "GammaDistribution" class (in Commons
> Math) accordingly.
>
> Regards,
> Gilles
>
>
>
> -
> 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 Commons Fileupload 1.3.3 based on RC5

[Rob Tompkins]

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

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

[Benedikt Ritter]

Hi Bruno,

> Am 06.06.2017 um 13:45 schrieb Bruno P. Kinoshita 
> :
> 
> 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.

Thank you so much!

Benedikt

> 
> 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  
> mons-lang/commit/eb2b89efbe15ab0b70fd94f0ecd0aa03866fb4d2#
> 
> diff-27e0ef6d1e59c634d3ba4d9cb05629a4R362>) caused this one. It doesn’t
> 
> make sense to me that it would, but it’s the only change to the code in
> 
> that area. Does the released version have the same issue?
> 
> 
> 
> Still investigating the second test failure. I’ll keep you guys posted
> 
> with anything I can come up with.
> 
> 
> 
> -Rob
> 
> 
> 
>> 
> 
>> at
> 
>> org.apache.commons.lang3.time.FastDateParser.parse(FastDateP
> 
> arser.java:369)
> 
>> 
> 
>> at
> 
>> org.apache.commons.lang3.time.FastDateParser_TimeZoneStrateg
> 
> yTest.testLang1219(FastDateParser_TimeZoneStrategyTest.java:62)
> 
>> 
> 
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Benedikt Ritter]

> Am 06.06.2017 um 14:00 schrieb Rob Tompkins :
> 
> 
> 
>> On Jun 6, 2017, at 7:48 AM, Benedikt Ritter  wrote:
>> 
>> Hi Rob,
>> 
>>> Am 05.06.2017 um 15:50 schrieb Rob Tompkins :
>>> 
>>> 
 On Jun 5, 2017, at 4:34 AM, Benedikt Ritter  wrote:
 
 Hi,
 
> Am 03.06.2017 um 18:54 schrieb Rob Tompkins  >:
> 
> This should be done now with the entries being “commons.module.name”
 
 I’d recommend using dashes in the second part of the name, since my 
 understanding of points is to declare name spaces. So I’d suggest to use 
 commons.automatic-module-name and not commons.automatic.module.name.
>>> 
>>> I’m ok with re-namespacing. I’ll try to get to that after I push out the 
>>> file upload 1.3.3 release.
>> 
>> Please make sure that this actually works and generates the desired MANIFEST 
>> entry. As I’ve said in my comment to one of the commits, I don’t understand 
>> who this is supposed to work without changing and releasing parent pom.
> 
> I was just trying to get ahead of the implied release of the parent Pom. I 
> agree that they do nothing until the consuming component up versions into the 
> new parent. Maybe that's too much pre-usefulness work?

Since we haven’t agreed upon a property name (my proposal is 
commons.automatic-module-name), I doubt that it may have been premature :-)

We still have that problem that I don’t know how to modify parent pom so that 
the manifest entry is opt-in...

Regards,
Benedikt

> 
>> 
>> Cheers,
>> Benedikt
>> 
>>> 
>>> -Rob
>>> 
 
 Benedikt
 
> 
> Cheers,
> -Rob
> 
>> On May 24, 2017, at 11:31 AM, Rob Tompkins  wrote:
>> 
>> 
>>> On May 24, 2017, at 11:11 AM, Stephen Colebourne  
>>> wrote:
>>> 
>>> On 24 May 2017 at 15:55, Rob Tompkins  wrote:
 We should simply add that entry, "commons.automatic-module-name," to 
 every component pom’s properties section now, and then when the next 
 parent migration happens, the changes will express naturally. It might 
 be worth adding a comment on the property in each pom?
 
 I’d be happy to do that between now and Monday.
>>> 
>>> As I said upthread, there is an argument to only add it to components
>>> once they have been checked to see if they are valid for use as a
>>> module.
>> 
>> Right.
>> 
>>> 
>>> That said, I'm willing to go with it as an approach because AFAICT if
>>> a component isn't a good modular citizen, the Automatic-Module-Name
>>> MANIFEST entry won't do much harm.
>> 
>> Yes.
>> 
>>> 
>>> Of course, strictly speaking we don't know if Automatic-Module-Name
>>> will be part of the final JDK 9, as private discussions are currently
>>> ongoing between the key players. Since it will cause no harm if
>>> wrongly present, I'm OK with this too,
>>> 
>>> If you are going to do it, I'd suggest using ${commons.module-name},
>> 
>> Makes sense to me there. I’m not the best at coming up with names. :-)
>> 
>>> as you will be adding the official module name for the component. That
>>> it is only used as the automatic module name right now is a detail.
>> 
>> I will start chipping away at this tomorrow or Friday, assuming that 
>> there aren’t any objections between now and then.
>> 
>> -Rob
>> 
>>> 
>>> Stephen
>>> 
>>> -
>>> 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 
 
>> 
>> 
>> -
>> 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: [all] Should our gitignore files contain only build-related entries?

[sebb]

On 6 June 2017 at 15:49, Matt Sicker  wrote:
> It might be useful to document a helpful starter .gitignore_global for
> users. I tend to set those up and forget about them.

+1

That sounds like a good addition to the Wiki

There is:

https://wiki.apache.org/commons/UsingGIT

That is quite long already, so a new page (linked from it) might be better.

> On 6 June 2017 at 06:50, Benedikt Ritter  wrote:
>
>> Hello Bernd,
>>
>> > Am 05.06.2017 um 18:47 schrieb Bernd Eckenfels :
>> >
>> > Are we talking about only the Maven profile or also about the Java
>> profile. I find that one overly eager and why does it contain BlueJ IDE
>> (only)?
>>
>> What are you referring to with „Maven profile“ and „Java profile“?
>>
>> Cheers,
>> Benedikt
>>
>> >
>> > Gruss
>> > Bernd
>> > --
>> > http://bernd.eckenfels.net
>> > 
>> > From: sebb 
>> > Sent: Monday, June 5, 2017 5:09:18 PM
>> > To: Commons Developers List
>> > Subject: Re: [all] Should our gitignore files contain only build-related
>> entries?
>> >
>> > On 5 June 2017 at 11:20, Benedikt Ritter  wrote:
>> >> Hi,
>> >>
>> >> I usually only use what gibo [1] generates. I don’t put editor specific
>> entries into .gitignore for my personal projects. This stuff should go into
>> your personal gitignore. If developers don’t know about global gitignore we
>> should educate them instead of promoting non-sense project setups.
>> >
>> > +1
>> >
>> >> Regards,
>> >> Benedikt
>> >>
>> >> [1] https://github.com/simonwhitaker/gibo
>> >>
>> >>> Am 01.06.2017 um 19:09 schrieb Gary Gregory :
>> >>>
>> >>> If we do not have per component .gitignore files, then we better have
>> clear
>> >>> instructions front and center on how to set up Git for what we expect.
>> >>>
>> >>> Gary
>> >>>
>> >>> On Wed, May 31, 2017 at 2:04 AM, Amey Jadiye 
>> wrote:
>> >>>
>>  Hi,
>> 
>>  I think easier way to have all ignorable extensions and directories in
>>  .gitignore and same have to be replicated in global gitignore from all
>>  other Commons projects. Commons is always having short fixes and
>>  improvements , people tend to fork>work>PR>delete repo on local pc.
>>  Instructions should be in UsingGIT and CONTRIBUTING.md but not sure
>> people
>>  will follow everything. Ignores already  present in .gitignore of each
>>  project makes everything painles.
>> 
>>  Regards,
>>  Amey
>> 
>>  On Sat, May 27, 2017, 7:03 PM Bruno P. Kinoshita
>>   wrote:
>> 
>> > Hi,
>> >
>> > [collections] recently received a pull request [1] to add VIM files
>> to
>>  the
>> > gitignore file. Its currently gitignore contains only a few entries
>> for
>> > Eclipse ([lang] has more entries for Eclipse).
>> >
>> > I remember asking something similar, and learning about the global
>> > gitignore. But besides that, in the same thread, Benedikt suggested
>>  having
>> > only build files ignored in our gitignore files [2], which I think
>> is a
>> > good idea. Our components do not follow any rule for gitignore files
>> I
>> > think. I normally check [lang] when I need to add a .gitignore to a
>> new
>> > computer, but just realized [text] and [lang] gitignore files differ
>> > ([lang] has a .checkstyle file under the Eclipse ignored files).
>> >
>> >
>> > I'm okay merging the pull request for [collections], but then we may
>> also
>> > add the remaining entries from [lang] there... except this pull
>> request
>> > adds *.swp which is missing from [lang]. So should we add it there
>> too?
>> >
>> > Some days ago I used NetBeans to test a generics suppress warning
>> message
>> > [3], but we may have developers using it as main IDE too. Would it
>> be all
>> > right to merge pull requests for it too? Or for files generated by
>>  plug-ins
>> > for Eclipse/IntelliJ/etc?
>> > What about 1) leaving only files generated by our build tools, 2)
>> add a
>> > comment to the .gitignore file describing how it works with links, 3)
>>  add a
>> > comment to
>> > https://wiki.apache.org/commons/UsingGIT and/or to the
>> CONTRIBUTING.md
>> > perhaps with a sample global gitignore file?
>> >
>> > Cheers
>> > Bruno
>> >
>> > [1] https://github.com/apache/commons-collections/pull/21
>> > [2]
>> > http://markmail.org/message/yvflc6kxgjalhldx?q=global+
>>  gitignore+list:org%2Eapache%2Ecommons%2Edev#query:global%
>>  20gitignore%20list%3Aorg.apache.commons.dev+page:1+mid:
>>  ioex63sxnf6culwb+state:results
>> > [3] https://github.com/apache/commons-collections/pull/17
>> >
>> > 
>> -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>> 
>> >>
>> >>
>> >> -

Re: [all] Should our gitignore files contain only build-related entries?

[Matt Sicker]

It might be useful to document a helpful starter .gitignore_global for
users. I tend to set those up and forget about them.

On 6 June 2017 at 06:50, Benedikt Ritter  wrote:

> Hello Bernd,
>
> > Am 05.06.2017 um 18:47 schrieb Bernd Eckenfels :
> >
> > Are we talking about only the Maven profile or also about the Java
> profile. I find that one overly eager and why does it contain BlueJ IDE
> (only)?
>
> What are you referring to with „Maven profile“ and „Java profile“?
>
> Cheers,
> Benedikt
>
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > 
> > From: sebb 
> > Sent: Monday, June 5, 2017 5:09:18 PM
> > To: Commons Developers List
> > Subject: Re: [all] Should our gitignore files contain only build-related
> entries?
> >
> > On 5 June 2017 at 11:20, Benedikt Ritter  wrote:
> >> Hi,
> >>
> >> I usually only use what gibo [1] generates. I don’t put editor specific
> entries into .gitignore for my personal projects. This stuff should go into
> your personal gitignore. If developers don’t know about global gitignore we
> should educate them instead of promoting non-sense project setups.
> >
> > +1
> >
> >> Regards,
> >> Benedikt
> >>
> >> [1] https://github.com/simonwhitaker/gibo
> >>
> >>> Am 01.06.2017 um 19:09 schrieb Gary Gregory :
> >>>
> >>> If we do not have per component .gitignore files, then we better have
> clear
> >>> instructions front and center on how to set up Git for what we expect.
> >>>
> >>> Gary
> >>>
> >>> On Wed, May 31, 2017 at 2:04 AM, Amey Jadiye 
> wrote:
> >>>
>  Hi,
> 
>  I think easier way to have all ignorable extensions and directories in
>  .gitignore and same have to be replicated in global gitignore from all
>  other Commons projects. Commons is always having short fixes and
>  improvements , people tend to fork>work>PR>delete repo on local pc.
>  Instructions should be in UsingGIT and CONTRIBUTING.md but not sure
> people
>  will follow everything. Ignores already  present in .gitignore of each
>  project makes everything painles.
> 
>  Regards,
>  Amey
> 
>  On Sat, May 27, 2017, 7:03 PM Bruno P. Kinoshita
>   wrote:
> 
> > Hi,
> >
> > [collections] recently received a pull request [1] to add VIM files
> to
>  the
> > gitignore file. Its currently gitignore contains only a few entries
> for
> > Eclipse ([lang] has more entries for Eclipse).
> >
> > I remember asking something similar, and learning about the global
> > gitignore. But besides that, in the same thread, Benedikt suggested
>  having
> > only build files ignored in our gitignore files [2], which I think
> is a
> > good idea. Our components do not follow any rule for gitignore files
> I
> > think. I normally check [lang] when I need to add a .gitignore to a
> new
> > computer, but just realized [text] and [lang] gitignore files differ
> > ([lang] has a .checkstyle file under the Eclipse ignored files).
> >
> >
> > I'm okay merging the pull request for [collections], but then we may
> also
> > add the remaining entries from [lang] there... except this pull
> request
> > adds *.swp which is missing from [lang]. So should we add it there
> too?
> >
> > Some days ago I used NetBeans to test a generics suppress warning
> message
> > [3], but we may have developers using it as main IDE too. Would it
> be all
> > right to merge pull requests for it too? Or for files generated by
>  plug-ins
> > for Eclipse/IntelliJ/etc?
> > What about 1) leaving only files generated by our build tools, 2)
> add a
> > comment to the .gitignore file describing how it works with links, 3)
>  add a
> > comment to
> > https://wiki.apache.org/commons/UsingGIT and/or to the
> CONTRIBUTING.md
> > perhaps with a sample global gitignore file?
> >
> > Cheers
> > Bruno
> >
> > [1] https://github.com/apache/commons-collections/pull/21
> > [2]
> > http://markmail.org/message/yvflc6kxgjalhldx?q=global+
>  gitignore+list:org%2Eapache%2Ecommons%2Edev#query:global%
>  20gitignore%20list%3Aorg.apache.commons.dev+page:1+mid:
>  ioex63sxnf6culwb+state:results
> > [3] https://github.com/apache/commons-collections/pull/17
> >
> > 
> -
> > 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.

[EXEC] Issue with Apache Commons Exec

[Dan Carissimo]

Hi,
I'm new to using Apache Commons Exec Version 1.3 and I've got a strange one
that I can't seem to figure out.  I'm getting the following stack trace
when I run :

org.apache.commons.exec.ExecuteException: The stop timeout of 30 ms was
exceeded (Exit value: -559038737)
org.apache.commons.exec.ExecuteException: The stop timeout of 30 ms was
exceeded (Exit value: -559038737)
at org.apache.commons.exec.PumpStreamHandler.stopThread
(PumpStreamHandler.java:295)
at org.apache.commons.exec.PumpStreamHandler.stop
(PumpStreamHandler.java:181)
at org.apache.commons.exec.DefaultExecutor.executeInternal
(DefaultExecutor.java:381)
at org.apache.commons.exec.DefaultExecutor.execute
(DefaultExecutor.java:166)
at com.ibm.bmfuncsec.keymgmt.server.ExecuteCmd.execute
(ExecuteCmd.java:123)
at com.ibm.bmfuncsec.keymgmt.server.server$WorkerThread.run
(server.java:285)

When I look at the source for DefaultExecutor and PumpStreamHandler, it
appears to me that the external command that I've tried to run has
completed, and the commons exec code is trying to shutdown the threads that
capture stdout and stderr.  According to the timestamps, the exception is
created about 10 minutes after the external command has completed, but I've
set a timeout of 5 minutes ...

Here's what my source looks like :

CommandLine cmdLine = CommandLine.parse("/bin/bash " + cmd);

stdout = new ByteArrayOutputStream();
stderr = new ByteArrayOutputStream();
PumpStreamHandler psh = new PumpStreamHandler(stdout, stderr);

psh.setStopTimeout(TIMEOUT_FIVE_MINUTES);

ExecuteWatchdog watchdog = new ExecuteWatchdog
(TIMEOUT_TEN_MINUTES);   // timeout in milliseconds

Executor executor = new DefaultExecutor();
executor.setExitValue(0);
executor.setStreamHandler(psh);
executor.setWatchdog(watchdog);

exitValue = executor.execute(cmdLine, env);


private longTIMEOUT_ONE_SECOND  = 1000;
private longTIMEOUT_TEN_SECONDS = 10 * TIMEOUT_ONE_SECOND;
private longTIMEOUT_ONE_MINUTE  = 60 * TIMEOUT_ONE_SECOND;
private longTIMEOUT_FIVE_MINUTES= 5  * TIMEOUT_ONE_MINUTE;
private longTIMEOUT_TEN_MINUTES = 10 * TIMEOUT_ONE_MINUTE;

Can someone have a look at the above and let me know what the problem might
be and how do I fix it??

Thanks!!

Re: [LOGGING] Logging and Java 9 (Was: Re: Compiler targets and Java 9)

[Ralph Goers]

The latest discussions I read indicated that adding the automatic module entry 
to the manifest is NOT recommended unless the component is ready to be 
modularized except that it has downstream dependencies that are not modules.  

Ralph

> On Jun 6, 2017, at 5:18 AM, Jörg Schaible  
> wrote:
> 
> Hi Benedict,
> 
> Benedikt Ritter wrote:
> 
>> Hi,
>> 
>> (Moving this to a new topic, since it may cause a lengthy discussion :o))
>> 
>>> Am 05.06.2017 um 16:41 schrieb Jochen Wiedmann
>>> :
>>> 
>>> Hi,
>>> 
>>> thanks to Rob Rompkins, and his recent work on Fileupload, it came to
>>> my attention that Java 9 will no longer support JVM 1.5, and lower, as
>>> a compiler target. [1]
>>> 
>>> This means, that we will be preventing our developers from using Java
>>> 9, if a component is still below 1.6. (And, I'd expect that to be the
>>> case for quite some projects.)
>>> 
>>> Now, leaving the general discussions regarding Java 9, and (in
>>> particular) Jigsaw, aside, I think that is something that we ought to
>>> consider.
>>> 
>>> OTOH, it seems reasonable to expect that Java 9 adoption will be slow,
>>> given that it isn't upwards compatible.
>>> 
>>> So, as a  compromise, I propose that we adopt the following policy:
>>> 
>>> All commons proper components are expected within one year from now on
>>> to bump their compiler target to 1.6, or beyond, and have a release
>>> published with that target. That way, we know, that it works fine with
>>> the Java 9 compiler.
>> 
>> What about Logging? Logging is at Java 1.3 at the moment and we decided,
>> that we don’t want to touch that component since it is so widely spread. I
>> think our advice last time was to refer new users to use Log4j.
>> 
>> Do we apply the proposed policy to Logging nevertheless?
> 
> I'd be pragmatic. If laster CL runs in Java 9, then there's no action 
> required. If not, we may apply the policy for the mext minor version (and 
> also add a module name). A productive environment not running at least Java 
> 6 won't have to use this anyway.
> 
> - Jörg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> 
> For additional commands, e-mail: dev-h...@commons.apache.org 
> 

Re: [LOGGING] Logging and Java 9 (Was: Re: Compiler targets and Java 9)

[Jörg Schaible]

Hi Benedict,

Benedikt Ritter wrote:

> Hi,
> 
> (Moving this to a new topic, since it may cause a lengthy discussion :o))
> 
>> Am 05.06.2017 um 16:41 schrieb Jochen Wiedmann
>> :
>> 
>> Hi,
>> 
>> thanks to Rob Rompkins, and his recent work on Fileupload, it came to
>> my attention that Java 9 will no longer support JVM 1.5, and lower, as
>> a compiler target. [1]
>> 
>> This means, that we will be preventing our developers from using Java
>> 9, if a component is still below 1.6. (And, I'd expect that to be the
>> case for quite some projects.)
>> 
>> Now, leaving the general discussions regarding Java 9, and (in
>> particular) Jigsaw, aside, I think that is something that we ought to
>> consider.
>> 
>> OTOH, it seems reasonable to expect that Java 9 adoption will be slow,
>> given that it isn't upwards compatible.
>> 
>> So, as a  compromise, I propose that we adopt the following policy:
>> 
>> All commons proper components are expected within one year from now on
>> to bump their compiler target to 1.6, or beyond, and have a release
>> published with that target. That way, we know, that it works fine with
>> the Java 9 compiler.
> 
> What about Logging? Logging is at Java 1.3 at the moment and we decided,
> that we don’t want to touch that component since it is so widely spread. I
> think our advice last time was to refer new users to use Log4j.
> 
> Do we apply the proposed policy to Logging nevertheless?

I'd be pragmatic. If laster CL runs in Java 9, then there's no action 
required. If not, we may apply the policy for the mext minor version (and 
also add a module name). A productive environment not running at least Java 
6 won't have to use this anyway.

- Jörg


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

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Rob Tompkins]

> On Jun 6, 2017, at 7:48 AM, Benedikt Ritter  wrote:
> 
> Hi Rob,
> 
>> Am 05.06.2017 um 15:50 schrieb Rob Tompkins :
>> 
>> 
>>> On Jun 5, 2017, at 4:34 AM, Benedikt Ritter  wrote:
>>> 
>>> Hi,
>>> 
 Am 03.06.2017 um 18:54 schrieb Rob Tompkins >>> >:
 
 This should be done now with the entries being “commons.module.name”
>>> 
>>> I’d recommend using dashes in the second part of the name, since my 
>>> understanding of points is to declare name spaces. So I’d suggest to use 
>>> commons.automatic-module-name and not commons.automatic.module.name.
>> 
>> I’m ok with re-namespacing. I’ll try to get to that after I push out the 
>> file upload 1.3.3 release.
> 
> Please make sure that this actually works and generates the desired MANIFEST 
> entry. As I’ve said in my comment to one of the commits, I don’t understand 
> who this is supposed to work without changing and releasing parent pom.

I was just trying to get ahead of the implied release of the parent Pom. I 
agree that they do nothing until the consuming component up versions into the 
new parent. Maybe that's too much pre-usefulness work?

> 
> Cheers,
> Benedikt
> 
>> 
>> -Rob
>> 
>>> 
>>> Benedikt
>>> 
 
 Cheers,
 -Rob
 
> On May 24, 2017, at 11:31 AM, Rob Tompkins  wrote:
> 
> 
>> On May 24, 2017, at 11:11 AM, Stephen Colebourne  
>> wrote:
>> 
>> On 24 May 2017 at 15:55, Rob Tompkins  wrote:
>>> We should simply add that entry, "commons.automatic-module-name," to 
>>> every component pom’s properties section now, and then when the next 
>>> parent migration happens, the changes will express naturally. It might 
>>> be worth adding a comment on the property in each pom?
>>> 
>>> I’d be happy to do that between now and Monday.
>> 
>> As I said upthread, there is an argument to only add it to components
>> once they have been checked to see if they are valid for use as a
>> module.
> 
> Right.
> 
>> 
>> That said, I'm willing to go with it as an approach because AFAICT if
>> a component isn't a good modular citizen, the Automatic-Module-Name
>> MANIFEST entry won't do much harm.
> 
> Yes.
> 
>> 
>> Of course, strictly speaking we don't know if Automatic-Module-Name
>> will be part of the final JDK 9, as private discussions are currently
>> ongoing between the key players. Since it will cause no harm if
>> wrongly present, I'm OK with this too,
>> 
>> If you are going to do it, I'd suggest using ${commons.module-name},
> 
> Makes sense to me there. I’m not the best at coming up with names. :-)
> 
>> as you will be adding the official module name for the component. That
>> it is only used as the automatic module name right now is a detail.
> 
> I will start chipping away at this tomorrow or Friday, assuming that 
> there aren’t any objections between now and then.
> 
> -Rob
> 
>> 
>> Stephen
>> 
>> -
>> 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 
>>> 
> 
> 
> -
> 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

[LOGGING] Logging and Java 9 (Was: Re: Compiler targets and Java 9)

[Benedikt Ritter]

Hi,

(Moving this to a new topic, since it may cause a lengthy discussion :o))

> Am 05.06.2017 um 16:41 schrieb Jochen Wiedmann :
> 
> Hi,
> 
> thanks to Rob Rompkins, and his recent work on Fileupload, it came to
> my attention that Java 9 will no longer support JVM 1.5, and lower, as
> a compiler target. [1]
> 
> This means, that we will be preventing our developers from using Java
> 9, if a component is still below 1.6. (And, I'd expect that to be the
> case for quite some projects.)
> 
> Now, leaving the general discussions regarding Java 9, and (in
> particular) Jigsaw, aside, I think that is something that we ought to
> consider.
> 
> OTOH, it seems reasonable to expect that Java 9 adoption will be slow,
> given that it isn't upwards compatible.
> 
> So, as a  compromise, I propose that we adopt the following policy:
> 
> All commons proper components are expected within one year from now on
> to bump their compiler target to 1.6, or beyond, and have a release
> published with that target. That way, we know, that it works fine with
> the Java 9 compiler.

What about Logging? Logging is at Java 1.3 at the moment and we decided, that 
we don’t want to touch that component since it is so widely spread. I think our 
advice last time was to refer new users to use Log4j.

Do we apply the proposed policy to Logging nevertheless?

Benedikt

> 
> Jochen
> 
> 
> 
> 
> 1: http://openjdk.java.net/jeps/182
> 
> -- 
> The next time you hear: "Don't reinvent the wheel!"
> 
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> 
> -
> 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: Compiler targets and Java 9

[Benedikt Ritter]

> Am 05.06.2017 um 16:41 schrieb Jochen Wiedmann :
> 
> Hi,
> 
> thanks to Rob Rompkins, and his recent work on Fileupload, it came to
> my attention that Java 9 will no longer support JVM 1.5, and lower, as
> a compiler target. [1]
> 
> This means, that we will be preventing our developers from using Java
> 9, if a component is still below 1.6. (And, I'd expect that to be the
> case for quite some projects.)
> 
> Now, leaving the general discussions regarding Java 9, and (in
> particular) Jigsaw, aside, I think that is something that we ought to
> consider.
> 
> OTOH, it seems reasonable to expect that Java 9 adoption will be slow,
> given that it isn't upwards compatible.
> 
> So, as a  compromise, I propose that we adopt the following policy:
> 
> All commons proper components are expected within one year from now on
> to bump their compiler target to 1.6, or beyond, and have a release
> published with that target. That way, we know, that it works fine with
> the Java 9 compiler.

+1

Benedikt

> 
> Jochen
> 
> 
> 
> 
> 1: http://openjdk.java.net/jeps/182
> 
> -- 
> The next time you hear: "Don't reinvent the wheel!"
> 
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> 
> -
> 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: [all] Deploying components

[Benedikt Ritter]

Hello Stian,

> Am 05.06.2017 um 18:58 schrieb Stian Soiland-Reyes :
> 
> Personally I am happy about source distributions accompanying the jars in
> Maven Central, which are actually rebuildable as opposed to the
> -source.jars.
> 
> they continue to be retrievable using Maven version mechanisms, compares to
> more fragile scripts crawling archive.apache.org (dist only contains the
> latest version).
> 
> The -bin archives are less useful, however I have used their hashes during
> RC testing to confirm the jars in staging reasonably match the RC in dist
> (this can also be achieved by simply unpacking the binary dist and
> navigating to the jars)

It’s a PITA to manually commit the archive to the distilled area. This should 
be automated as part of the release process.

Regards,
Benedikt

> 
> 
> 
> On 28 May 2017 3:01 am, "Rob Tompkins"  wrote:
> 
>> Hello all,
>> 
>> Benedikt and I were chatting last week about how the .tar and .zip
>> distributions get uploaded to nexus during "mvn deploy” and how annoying
>> that side effect of the deployment happens to be. Coincidentally, I just
>> ran across a note that  Mladen Turk added at the end of the commons-daemon
>> release guide:
>> 
>> https://github.com/apache/commons-daemon/blob/trunk/
>> HOWTO-RELEASE.txt#L41-L43 > commons-daemon/blob/trunk/HOWTO-RELEASE.txt#L41-L43>
>> 
>> I’m thinking: (1) interesting note, knowing that the problem still exists,
>> and (2) I wonder if there would be community appetite for an attempt at
>> adding better automation to the release process. I’m betting that with a
>> little effort we probably could improve the release experience at least a
>> little.
>> 
>> Cheers,
>> -Rob


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

Re: [all] Should our gitignore files contain only build-related entries?

[Benedikt Ritter]

Hello Bernd,

> Am 05.06.2017 um 18:47 schrieb Bernd Eckenfels :
> 
> Are we talking about only the Maven profile or also about the Java profile. I 
> find that one overly eager and why does it contain BlueJ IDE (only)?

What are you referring to with „Maven profile“ and „Java profile“?

Cheers,
Benedikt

> 
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: sebb 
> Sent: Monday, June 5, 2017 5:09:18 PM
> To: Commons Developers List
> Subject: Re: [all] Should our gitignore files contain only build-related 
> entries?
> 
> On 5 June 2017 at 11:20, Benedikt Ritter  wrote:
>> Hi,
>> 
>> I usually only use what gibo [1] generates. I don’t put editor specific 
>> entries into .gitignore for my personal projects. This stuff should go into 
>> your personal gitignore. If developers don’t know about global gitignore we 
>> should educate them instead of promoting non-sense project setups.
> 
> +1
> 
>> Regards,
>> Benedikt
>> 
>> [1] https://github.com/simonwhitaker/gibo
>> 
>>> Am 01.06.2017 um 19:09 schrieb Gary Gregory :
>>> 
>>> If we do not have per component .gitignore files, then we better have clear
>>> instructions front and center on how to set up Git for what we expect.
>>> 
>>> Gary
>>> 
>>> On Wed, May 31, 2017 at 2:04 AM, Amey Jadiye  wrote:
>>> 
 Hi,
 
 I think easier way to have all ignorable extensions and directories in
 .gitignore and same have to be replicated in global gitignore from all
 other Commons projects. Commons is always having short fixes and
 improvements , people tend to fork>work>PR>delete repo on local pc.
 Instructions should be in UsingGIT and CONTRIBUTING.md but not sure people
 will follow everything. Ignores already  present in .gitignore of each
 project makes everything painles.
 
 Regards,
 Amey
 
 On Sat, May 27, 2017, 7:03 PM Bruno P. Kinoshita
  wrote:
 
> Hi,
> 
> [collections] recently received a pull request [1] to add VIM files to
 the
> gitignore file. Its currently gitignore contains only a few entries for
> Eclipse ([lang] has more entries for Eclipse).
> 
> I remember asking something similar, and learning about the global
> gitignore. But besides that, in the same thread, Benedikt suggested
 having
> only build files ignored in our gitignore files [2], which I think is a
> good idea. Our components do not follow any rule for gitignore files I
> think. I normally check [lang] when I need to add a .gitignore to a new
> computer, but just realized [text] and [lang] gitignore files differ
> ([lang] has a .checkstyle file under the Eclipse ignored files).
> 
> 
> I'm okay merging the pull request for [collections], but then we may also
> add the remaining entries from [lang] there... except this pull request
> adds *.swp which is missing from [lang]. So should we add it there too?
> 
> Some days ago I used NetBeans to test a generics suppress warning message
> [3], but we may have developers using it as main IDE too. Would it be all
> right to merge pull requests for it too? Or for files generated by
 plug-ins
> for Eclipse/IntelliJ/etc?
> What about 1) leaving only files generated by our build tools, 2) add a
> comment to the .gitignore file describing how it works with links, 3)
 add a
> comment to
> https://wiki.apache.org/commons/UsingGIT and/or to the CONTRIBUTING.md
> perhaps with a sample global gitignore file?
> 
> Cheers
> Bruno
> 
> [1] https://github.com/apache/commons-collections/pull/21
> [2]
> http://markmail.org/message/yvflc6kxgjalhldx?q=global+
 gitignore+list:org%2Eapache%2Ecommons%2Edev#query:global%
 20gitignore%20list%3Aorg.apache.commons.dev+page:1+mid:
 ioex63sxnf6culwb+state:results
> [3] https://github.com/apache/commons-collections/pull/17
> 
> -
> 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
> 


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

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Benedikt Ritter]

Hi Rob,

> Am 05.06.2017 um 15:50 schrieb Rob Tompkins :
> 
> 
>> On Jun 5, 2017, at 4:34 AM, Benedikt Ritter  wrote:
>> 
>> Hi,
>> 
>>> Am 03.06.2017 um 18:54 schrieb Rob Tompkins >> >:
>>> 
>>> This should be done now with the entries being “commons.module.name”
>> 
>> I’d recommend using dashes in the second part of the name, since my 
>> understanding of points is to declare name spaces. So I’d suggest to use 
>> commons.automatic-module-name and not commons.automatic.module.name.
> 
> I’m ok with re-namespacing. I’ll try to get to that after I push out the file 
> upload 1.3.3 release.

Please make sure that this actually works and generates the desired MANIFEST 
entry. As I’ve said in my comment to one of the commits, I don’t understand who 
this is supposed to work without changing and releasing parent pom.

Cheers,
Benedikt

> 
> -Rob
> 
>> 
>> Benedikt
>> 
>>> 
>>> Cheers,
>>> -Rob
>>> 
 On May 24, 2017, at 11:31 AM, Rob Tompkins  wrote:
 
 
> On May 24, 2017, at 11:11 AM, Stephen Colebourne  
> wrote:
> 
> On 24 May 2017 at 15:55, Rob Tompkins  wrote:
>> We should simply add that entry, "commons.automatic-module-name," to 
>> every component pom’s properties section now, and then when the next 
>> parent migration happens, the changes will express naturally. It might 
>> be worth adding a comment on the property in each pom?
>> 
>> I’d be happy to do that between now and Monday.
> 
> As I said upthread, there is an argument to only add it to components
> once they have been checked to see if they are valid for use as a
> module.
 
 Right.
 
> 
> That said, I'm willing to go with it as an approach because AFAICT if
> a component isn't a good modular citizen, the Automatic-Module-Name
> MANIFEST entry won't do much harm.
 
 Yes.
 
> 
> Of course, strictly speaking we don't know if Automatic-Module-Name
> will be part of the final JDK 9, as private discussions are currently
> ongoing between the key players. Since it will cause no harm if
> wrongly present, I'm OK with this too,
> 
> If you are going to do it, I'd suggest using ${commons.module-name},
 
 Makes sense to me there. I’m not the best at coming up with names. :-)
 
> as you will be adding the official module name for the component. That
> it is only used as the automatic module name right now is a detail.
 
 I will start chipping away at this tomorrow or Friday, assuming that there 
 aren’t any objections between now and then.
 
 -Rob
 
> 
> Stephen
> 
> -
> 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 
>> 


-
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)

[Bruno P. Kinoshita]

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 ) caused this one. It doesn’t

 make sense to me that it would, but it’s the only change to the code in

 that area. Does the released version have the same issue?

 

 Still investigating the second test failure. I’ll keep you guys posted

 with anything I can come up with.

 

 -Rob

 

> 

> at

> org.apache.commons.lang3.time.FastDateParser.parse(FastDateP

 arser.java:369)

> 

> at

> org.apache.commons.lang3.time.FastDateParser_TimeZoneStrateg

 yTest.testLang1219(FastDateParser_TimeZoneStrategyTest.java:62)

> 

> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

> 

> at

> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce

 ssorImpl.java:95)

> 

> at

> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe

 thodAccessorImpl.java:55)

> 

> at java.lang.reflect.Method.invoke(Method.java:508)

> 

> at

> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(

 FrameworkMethod.java:50)

> 

> at

> org.junit.internal.runners.model.Ref

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

[Bruno P. Kinoshita]

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 ) caused this one. It doesn’t
 make sense to me that it would, but it’s the only change to the code in
 that area. Does the released version have the same issue?
 
 Still investigating the second test failure. I’ll keep you guys posted
 with anything I can come up with.
 
 -Rob
 
> 
> at
> org.apache.commons.lang3.time.FastDateParser.parse(FastDateP
 arser.java:369)
> 
> at
> org.apache.commons.lang3.time.FastDateParser_TimeZoneStrateg
 yTest.testLang1219(FastDateParser_TimeZoneStrategyTest.java:62)
> 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
 ssorImpl.java:95)
> 
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
 thodAccessorImpl.java:55)
> 
> at java.lang.reflect.Method.invoke(Method.java:508)
> 
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
 FrameworkMethod.java:50)
> 
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(Refl
 ectiveCallable.java:12)
> 
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr
 ameworkMethod.java:47)
> 
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(
 InvokeMethod.java:17)
> 
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit
 4ClassRunner.java:78)
> 
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit
 4ClassRunner.java:57)
> 
> at org.junit.runners.ParentRunner$3.run(Paren

Re: [collections] Uniform null-safe methods in CollectionUtils

[Bruno P. Kinoshita]

Hi Benedikt,
Sounds good to me. There is a user interested in that issue too, so will check 
what he suggests as well. Will ping Thomas Neidhart too to check what he thinks 
as I think he was driving the changes in the last releases of collections.
CheersBruno

  From: Benedikt Ritter 
 To: Commons Developers List ; Bruno P. Kinoshita 
 
 Sent: Monday, 5 June 2017 10:44 PM
 Subject: Re: [collections] Uniform null-safe methods in CollectionUtils
   
Hello Bruno,

> Am 27.05.2017 um 15:40 schrieb Bruno P. Kinoshita 
> :
> 
> Hi,
> 
> COLLECTIONS-600 [1] received a pull request [2] to make a method in 
> CollectionUtils null-safe. Before merging it, I decided to check what was the 
> current approach in this class for handling null in methods.
> 
> COLLECTIONS-604 [3] contains the CSV file with the methods names and current 
> behaviour. TL;DR "Currently, there are 65 public methods in 
> `CollectionUtils`. And 53 without the deprecated ones. Out of these, 24 
> handle `null` arguments. The remaining methods throw a `NullPointerException` 
> (NPE) at some part of its code."
> 
> There are also cases where the javadocs suggest a NPE if any of the arguments 
> is null, but there are no if's checking if it is null, instead it relies on a 
> call to a member of the object to raise the NPE, or the intriguing case of 
> CollectionUtils.isEmpty(null) which returns true, and 
> CollectionUtils.isFull(null) which throws NPE (even though there is a 
> isNotEmpty, I'd expect isEmpty and isFull to be in some way related and have 
> similar behaviour).
> 
> Should we just work method per method and make it null-safe if necessary, or 
> should we define a common behaviour to all of its methods? I can see some 
> advantages of the latter for users, but am still not sure which approach to 
> take here.

Nobody seems to have an opinion on this issue so you should start implementing 
your preference.

Regards,
Benedikt

> 
> Cheers
> Bruno
> 
> [1] https://issues.apache.org/jira/browse/COLLECTIONS-600
> [2] https://github.com/apache/commons-collections/pull/22
> [3] https://issues.apache.org/jira/browse/COLLECTIONS-604
> 
> -
> 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: [all] Should our gitignore files contain only build-related entries?

[Bruno P. Kinoshita]

I can understand trying to make it easier for people to contribute too, but I 
still prefer to have a more IDE agnostic set up, with build-only files in the 
.gitignore file, and a global exclusion list. But I think we didn't reach a 
consensus here, so guess we will just keep the per project setting, and merge 
the pull requests as they come in and try to keep things as concise as possible.
Cheers
Bruno

  From: sebb 
 To: Commons Developers List  
 Sent: Tuesday, 6 June 2017 3:09 AM
 Subject: Re: [all] Should our gitignore files contain only build-related 
entries?
   
On 5 June 2017 at 11:20, Benedikt Ritter  wrote:
> Hi,
>
> I usually only use what gibo [1] generates. I don’t put editor specific 
> entries into .gitignore for my personal projects. This stuff should go into 
> your personal gitignore. If developers don’t know about global gitignore we 
> should educate them instead of promoting non-sense project setups.

+1

> Regards,
> Benedikt
>
> [1] https://github.com/simonwhitaker/gibo
>
>> Am 01.06.2017 um 19:09 schrieb Gary Gregory :
>>
>> If we do not have per component .gitignore files, then we better have clear
>> instructions front and center on how to set up Git for what we expect.
>>
>> Gary
>>
>> On Wed, May 31, 2017 at 2:04 AM, Amey Jadiye  wrote:
>>
>>> Hi,
>>>
>>> I think easier way to have all ignorable extensions and directories in
>>> .gitignore and same have to be replicated in global gitignore from all
>>> other Commons projects. Commons is always having short fixes and
>>> improvements , people tend to fork>work>PR>delete repo on local pc.
>>> Instructions should be in UsingGIT and CONTRIBUTING.md but not sure people
>>> will follow everything. Ignores already  present in .gitignore of each
>>> project makes everything painles.
>>>
>>> Regards,
>>> Amey
>>>
>>> On Sat, May 27, 2017, 7:03 PM Bruno P. Kinoshita
>>>  wrote:
>>>
 Hi,

 [collections] recently received a pull request [1] to add VIM files to
>>> the
 gitignore file. Its currently gitignore contains only a few entries for
 Eclipse ([lang] has more entries for Eclipse).

 I remember asking something similar, and learning about the global
 gitignore. But besides that, in the same thread, Benedikt suggested
>>> having
 only build files ignored in our gitignore files [2], which I think is a
 good idea. Our components do not follow any rule for gitignore files I
 think. I normally check [lang] when I need to add a .gitignore to a new
 computer, but just realized [text] and [lang] gitignore files differ
 ([lang] has a .checkstyle file under the Eclipse ignored files).


 I'm okay merging the pull request for [collections], but then we may also
 add the remaining entries from [lang] there... except this pull request
 adds *.swp which is missing from [lang]. So should we add it there too?

 Some days ago I used NetBeans to test a generics suppress warning message
 [3], but we may have developers using it as main IDE too. Would it be all
 right to merge pull requests for it too? Or for files generated by
>>> plug-ins
 for Eclipse/IntelliJ/etc?
 What about 1) leaving only files generated by our build tools, 2) add a
 comment to the .gitignore file describing how it works with links, 3)
>>> add a
 comment to
 https://wiki.apache.org/commons/UsingGIT and/or to the CONTRIBUTING.md
 perhaps with a sample global gitignore file?

 Cheers
 Bruno

 [1] https://github.com/apache/commons-collections/pull/21
 [2]
 http://markmail.org/message/yvflc6kxgjalhldx?q=global+
>>> gitignore+list:org%2Eapache%2Ecommons%2Edev#query:global%
>>> 20gitignore%20list%3Aorg.apache.commons.dev+page:1+mid:
>>> ioex63sxnf6culwb+state:results
 [3] https://github.com/apache/commons-collections/pull/17

 -
 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