Re: Compiler targets and Java 9

[Ralph Goers]

> On Jun 5, 2017, at 2:58 PM, Ralph Goers  wrote:
> 
> 
>> On Jun 5, 2017, at 1:00 PM, Amey Jadiye  wrote:
>> 
>> correct, moving to Java9 might be restricting 1.5 to run on higher
>> versions, that said they may not run on java 9 so all this discussion came
>> in picture, I wish we can have java 9 target well at the same time we
>> should detach our self from java 1.5, just a view.
>> 
>> Regards,
> 
> Java 5 artifacts should run just fine on Java 9 - with the exception that if 
> they are using restricted classes they will fail.  That is really the only 
> Java 9 issue to be concerned with, and is why it is going to take quite a bit 
> of time for it to become mainstream.
> 

And it seems my worry over those issues may have just been mitigated - 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-June/012841.html 
.

Ralph

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

[sesuncedu]

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
A key point is that these  files that are not modified for each release.
They are only changed when the package version changes, which only happens
when  the API changes (and was supposed to).
If the package API does  not change, then the package version should _not_
be modified.

Also, changing the package version number happens in the development phase
of the lifecycle rather than the release phase.

On Mon, Jun 5, 2017, 6:26 PM Jörg Schaible  
wrote:

> ... and again we have a bunch of files that we have to modify for every
> release.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



---
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-compress issue #26: COMPRESS-399 OSGI package versions are overly pe...

[joehni]

Github user joehni commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
... and again we have a bunch of files that we have to modify for every 
release.


---
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: Compiler targets and Java 9

[Gary Gregory]

On Mon, Jun 5, 2017 at 2:56 PM, Ralph Goers 
wrote:

>
> > On Jun 5, 2017, at 1:35 PM, sebb  wrote:
> >
> > On 5 June 2017 at 21:06, Ralph Goers  > wrote:
> >> OK. Who cares if their last release was Java 1.5? They will never
> release another version that supports it.
> >
> > Not sure who you mean by 'they' here.
>
> They is any component whose latest release is on Java 1.5.
>
> >
> > This thread is about Commons components whose latest release is 1.5 or
> > earlier, and what to do about it now that Java 9+ no longer supports
> > 1.5 as a compiler option.
>
> The answer is clear. There is no problem using a component compiled for
> Java 5, so this discussion is only about performing new releases of things.
> Any component that has a latest release based on Java 5 will continue to
> lay dormant until someone wants to do a new release of it. If and when that
> happens the next release will use Java 6 or hopefully, Java 7 (since Java 6
> has already reached end-of-life as well but has about another year before
> full end of support). There is no point in doing security fixes for
> anything based on Java 5 (or 6 in my opinion).
>
> This discussion about Java 9 is just a red herring as it is forcing you to
> have a discussion you really shouldn’t need to have. This upgrade should
> have been forced eons ago.
>

+1

Gary


>
> Ralph
>
>

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

[Gilles]

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

[Ralph Goers]

> On Jun 5, 2017, at 1:00 PM, Amey Jadiye  wrote:
> 
> correct, moving to Java9 might be restricting 1.5 to run on higher
> versions, that said they may not run on java 9 so all this discussion came
> in picture, I wish we can have java 9 target well at the same time we
> should detach our self from java 1.5, just a view.
> 
> Regards,

Java 5 artifacts should run just fine on Java 9 - with the exception that if 
they are using restricted classes they will fail.  That is really the only Java 
9 issue to be concerned with, and is why it is going to take quite a bit of 
time for it to become mainstream.

Ralph



-
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

[Ralph Goers]

> On Jun 5, 2017, at 1:35 PM, sebb  wrote:
> 
> On 5 June 2017 at 21:06, Ralph Goers  > wrote:
>> OK. Who cares if their last release was Java 1.5? They will never release 
>> another version that supports it.
> 
> Not sure who you mean by 'they' here.

They is any component whose latest release is on Java 1.5.

> 
> This thread is about Commons components whose latest release is 1.5 or
> earlier, and what to do about it now that Java 9+ no longer supports
> 1.5 as a compiler option.

The answer is clear. There is no problem using a component compiled for Java 5, 
so this discussion is only about performing new releases of things. Any 
component that has a latest release based on Java 5 will continue to lay 
dormant until someone wants to do a new release of it. If and when that happens 
the next release will use Java 6 or hopefully, Java 7 (since Java 6 has already 
reached end-of-life as well but has about another year before full end of 
support). There is no point in doing security fixes for anything based on Java 
5 (or 6 in my opinion).

This discussion about Java 9 is just a red herring as it is forcing you to have 
a discussion you really shouldn’t need to have. This upgrade should have been 
forced eons ago.

Ralph

Re: [all] Deploying components

[Gary Gregory]

I have used bin zips before to get to DLL files for example.

Gary

On Jun 5, 2017 9:58 AM, "Stian Soiland-Reyes"  wrote:

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

Re: Compiler targets and Java 9

[sebb]

On 5 June 2017 at 21:06, Ralph Goers  wrote:
> OK. Who cares if their last release was Java 1.5? They will never release 
> another version that supports it.

Not sure who you mean by 'they' here.

This thread is about Commons components whose latest release is 1.5 or
earlier, and what to do about it now that Java 9+ no longer supports
1.5 as a compiler option.

> Ralph
>
>> On Jun 5, 2017, at 12:55 PM, sebb  wrote:
>>
>> On 5 June 2017 at 20:26, Amey Jadiye > > wrote:
>>> +1
>>>
>>> I have seen hundreds of applications which are in (maintenance+ little
>>> enhancement) mode are already moved to higher versions of java ( >1.5 ),
>>> even very legacy applications which are just in maintenance mode or marked
>>> for decommission are already running on 1.6 as all know that there will be
>>> no updates. there could be rarest of rare applications running on 1.5 and
>>> sure they dont want move else they could have moved long back to 1.6 and
>>> and rarely 1.5 will move to java8 or 9 ;)
>>>
>>> so yeah, why are we discussing support for Java 1.5 when not even the
>>> vendors who ship it support it ? just move our modules for >=1.6.
>>
>> This thread is *not* about support for 1.5.
>>
>> It's about supporting Java 9, and what to do about components whose
>> last release is 1.5 or earlier.
>>
>> That is very different.
>>
>>> Regards,
>>> Amey
>>>
>>> On Mon, Jun 5, 2017 at 10:24 PM, Ralph Goers 
>>> wrote:
>>>
 This whole discussion has me really confused.  According to
 https://en.wikipedia.org/wiki/Java_version_history <
 https://en.wikipedia.org/wiki/Java_version_history> the free version of
 Java 5 reached end-of-life in 2009 and Oracle's supported version reached
 end-of-life in 2015. https://developer.ibm.com/javasdk/support/lifecycle/
  doesn’t even show
 Java 5 any more but https://www.ibm.com/developerworks/community/
 forums/html/topic?id=----14807464 <
 https://www.ibm.com/developerworks/community/
 forums/html/topic?id=----14807464> indicates that
 it also was dropped in 2015.

 So why are we discussing support for Java 1.5 when not even the vendors
 who ship it support it?

 Ralph


> On Jun 5, 2017, at 9:45 AM, Gary Gregory  wrote:
>
> On Mon, Jun 5, 2017 at 9:17 AM, Jochen Wiedmann <
 jochen.wiedm...@gmail.com >
> wrote:
>
>> On Mon, Jun 5, 2017 at 5:20 PM, sebb  wrote:
>>
 I'd like us to be able to push out a new release with minimal changes
 at any given time. If we have, for example, 1.6 as the target, and the
 previous
 release had 1.5 as the target, then we'd loose that ability, IMO.
 (Think security releases.We've had quite a few in the past.)
>>>
>>> Understood, but I'm not sure why you feel the lack of a 1.6 release
>>> would prevent a security release.
>>> Surely we could just apply the fixes to the previously released code
>>> and change to 1.6 at the same time?
>>
>> Because the result clearly be binary incompatible to its predecessor,
>> and that's the whole point of such an emergency release. We'd want a
>> drop-in replacement.
>>
>
> If someone wants a fix for something that runs on 1.5, they are welcome
 to
> provide a PR. I do not think we need to handcuff ourselves to Java 5. If
> your runtime is stuck on Java 5, your likely to have other more pressing
> security issues to address...
>
> Gary
>
>>
>> Jochen
>>
>>
>> --
>> The next time you hear: "Don't reinvent the wheel!"
>>
>> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/ <
 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 >>> dev-unsubscr...@commons.apache.org>
>> For additional commands, e-mail: dev-h...@commons.apache.org >>> 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 

[GitHub] commons-compress pull request #27: COMPRESS-400

[sesuncedu]

GitHub user sesuncedu opened a pull request:

https://github.com/apache/commons-compress/pull/27

COMPRESS-400 

Add extra header map to tar archive entry.
Move PAX header processing code from TarArchiveInputStream to 
TarAchiveEntry.
Use same code for processing user supplied extra headers - thus setting 
"size "changes the value of getSize().
Add any extra PAX headers to output map when putting entry in 
TarArchiveOutputStream.
Add simple tests for getting/setting xattr, setting "size", and round 
tripping.

This PR uses COMPRESS-399 as a base.  
To make it easier to cherry-pick + rebase the PR has been split in two.

 1d9b3c88455caceca81f0ff6b7eca0958c631359 contains just the code changes 
and test changes,  and does not bump the minor package version .  This will 
cause the bundle:baseline verify goal in 399 to  break the build.

82405c13bd2688817108d3f2854387b3417a764d  increases the package minor 
version to the correct value



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

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-400

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

https://github.com/apache/commons-compress/pull/27.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 #27


commit 109b14915cf594e5c2031e58d6f2fd0595fc184f
Author: Simon Spero 
Date:   2017-06-02T17:25:02Z

COMPRESS-399 OSGI package versions are overly pessimistic, except when 
they're overly optimisic

Add packageinfo files for per-package version settings. Initialize to 1.14
Copy packageinfo files in resource phase.

Use latest bundle plugin.
Remove superflous headers from manifest.
Pretty-print the manifest.
Add bundle:baseline to the verify phase
Add bundle:baseline-report to the site phase
To change the base version from default (i.e. previous release) set 
comparisonVersion property

Change travis build goal to verify

Signed-off-by: Simon Spero 

commit 3653a2e19b51c9bd894e3928ed959c0132afd9b6
Author: Simon  Spero 
Date:   2017-06-02T17:37:53Z

Default rat doesn't ignore packageinfo

One line of non copyrightable material does not need the license header  :)

commit 27b65778eee34805838a0e43777b98fb6714dc2a
Author: Simon Spero 
Date:   2017-06-05T15:55:18Z

Replace packageinfo files with annotated package-info.java as source of 
version info.
Add build time dependency on org,osgi.annotation for Version annotation.
Remove resource copy.

Signed-off-by: Simon Spero 

commit 1d9b3c88455caceca81f0ff6b7eca0958c631359
Author: Simon Spero 
Date:   2017-06-05T19:58:27Z

COMPRESS-400 It should be possible for users to create and access extra PAX 
headers to tar archives

Add extra header map to tar archive entry.
Move PAX header processing code from TarArchiveInputStream to 
TarAchiveEntry.
Use same code for processing user supplied extra headers - thus setting 
"size "changes the value of getSize().
Add any extra PAX headers to output map when putting entry in 
TarArchiveOutputStream.
Add simple tests for getting/setting xattr, setting "size", and round 
tripping.

This PR uses COMPRESS-399 as a base.  To make it easier to cherry-pick, 
this commit does not bump the minor
package version;  this will cause the baseline verify stage in 399 to  
break the build, since the API has changed in a backwards compatible fashion

A separate commit increases the package minor version.

Signed-off-by: Simon Spero 

commit 82405c13bd2688817108d3f2854387b3417a764d
Author: Simon Spero 
Date:   2017-06-05T20:02:32Z

Increase the minor package version for
org.apache.commons.compress.archivers.tar to 1.15.0 to reflect
backwards compatible changes to API:

[INFO] < org.apache.commons.compress.archivers.tar  minor  
1.15.0 1.14.0 1.15.0 -
[INFO]  < class 
org.apache.commons.compress.archivers.tar.TarArchiveEntry
[INFO]  + method addPaxHeader(java.lang.String,java.lang.String)
[INFO]  + method addXattr(java.lang.String,java.lang.String)
[INFO]  + method clearExtraPaxHeaders()
[INFO]  + method getExtraPaxHeader(java.lang.String)
[INFO]  + return java.lang.String
[INFO]  + method getExtraPaxHeaders()
[INFO]  + return 
java.util.Map
[INFO]  + method getXattr(java.lang.String)
[INFO]  + return java.lang.String
[INFO]  - version 1.14.0
[INFO]  + version 1.15.0

Signed-off-by: Simon Spero 

Re: Compiler targets and Java 9

[Ralph Goers]

OK. Who cares if their last release was Java 1.5? They will never release 
another version that supports it.

Ralph

> On Jun 5, 2017, at 12:55 PM, sebb  wrote:
> 
> On 5 June 2017 at 20:26, Amey Jadiye  > wrote:
>> +1
>> 
>> I have seen hundreds of applications which are in (maintenance+ little
>> enhancement) mode are already moved to higher versions of java ( >1.5 ),
>> even very legacy applications which are just in maintenance mode or marked
>> for decommission are already running on 1.6 as all know that there will be
>> no updates. there could be rarest of rare applications running on 1.5 and
>> sure they dont want move else they could have moved long back to 1.6 and
>> and rarely 1.5 will move to java8 or 9 ;)
>> 
>> so yeah, why are we discussing support for Java 1.5 when not even the
>> vendors who ship it support it ? just move our modules for >=1.6.
> 
> This thread is *not* about support for 1.5.
> 
> It's about supporting Java 9, and what to do about components whose
> last release is 1.5 or earlier.
> 
> That is very different.
> 
>> Regards,
>> Amey
>> 
>> On Mon, Jun 5, 2017 at 10:24 PM, Ralph Goers 
>> wrote:
>> 
>>> This whole discussion has me really confused.  According to
>>> https://en.wikipedia.org/wiki/Java_version_history <
>>> https://en.wikipedia.org/wiki/Java_version_history> the free version of
>>> Java 5 reached end-of-life in 2009 and Oracle's supported version reached
>>> end-of-life in 2015. https://developer.ibm.com/javasdk/support/lifecycle/
>>>  doesn’t even show
>>> Java 5 any more but https://www.ibm.com/developerworks/community/
>>> forums/html/topic?id=----14807464 <
>>> https://www.ibm.com/developerworks/community/
>>> forums/html/topic?id=----14807464> indicates that
>>> it also was dropped in 2015.
>>> 
>>> So why are we discussing support for Java 1.5 when not even the vendors
>>> who ship it support it?
>>> 
>>> Ralph
>>> 
>>> 
 On Jun 5, 2017, at 9:45 AM, Gary Gregory  wrote:
 
 On Mon, Jun 5, 2017 at 9:17 AM, Jochen Wiedmann <
>>> jochen.wiedm...@gmail.com >
 wrote:
 
> On Mon, Jun 5, 2017 at 5:20 PM, sebb  wrote:
> 
>>> I'd like us to be able to push out a new release with minimal changes
>>> at any given time. If we have, for example, 1.6 as the target, and the
>>> previous
>>> release had 1.5 as the target, then we'd loose that ability, IMO.
>>> (Think security releases.We've had quite a few in the past.)
>> 
>> Understood, but I'm not sure why you feel the lack of a 1.6 release
>> would prevent a security release.
>> Surely we could just apply the fixes to the previously released code
>> and change to 1.6 at the same time?
> 
> Because the result clearly be binary incompatible to its predecessor,
> and that's the whole point of such an emergency release. We'd want a
> drop-in replacement.
> 
 
 If someone wants a fix for something that runs on 1.5, they are welcome
>>> to
 provide a PR. I do not think we need to handcuff ourselves to Java 5. If
 your runtime is stuck on Java 5, your likely to have other more pressing
 security issues to address...
 
 Gary
 
> 
> Jochen
> 
> 
> --
> The next time you hear: "Don't reinvent the wheel!"
> 
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/ <
>>> 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 >> dev-unsubscr...@commons.apache.org>
> For additional commands, e-mail: dev-h...@commons.apache.org >> 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: Compiler targets and Java 9

[Amey Jadiye]

correct, moving to Java9 might be restricting 1.5 to run on higher
versions, that said they may not run on java 9 so all this discussion came
in picture, I wish we can have java 9 target well at the same time we
should detach our self from java 1.5, just a view.

Regards,
Amey

On Tue, Jun 6, 2017 at 1:25 AM, sebb  wrote:

> On 5 June 2017 at 20:26, Amey Jadiye  wrote:
> > +1
> >
> > I have seen hundreds of applications which are in (maintenance+ little
> > enhancement) mode are already moved to higher versions of java ( >1.5 ),
> > even very legacy applications which are just in maintenance mode or
> marked
> > for decommission are already running on 1.6 as all know that there will
> be
> > no updates. there could be rarest of rare applications running on 1.5 and
> > sure they dont want move else they could have moved long back to 1.6 and
> > and rarely 1.5 will move to java8 or 9 ;)
> >
> > so yeah, why are we discussing support for Java 1.5 when not even the
> > vendors who ship it support it ? just move our modules for >=1.6.
>
> This thread is *not* about support for 1.5.
>
> It's about supporting Java 9, and what to do about components whose
> last release is 1.5 or earlier.
>
> That is very different.
>
> > Regards,
> > Amey
> >
> > On Mon, Jun 5, 2017 at 10:24 PM, Ralph Goers  >
> > wrote:
> >
> >> This whole discussion has me really confused.  According to
> >> https://en.wikipedia.org/wiki/Java_version_history <
> >> https://en.wikipedia.org/wiki/Java_version_history> the free version of
> >> Java 5 reached end-of-life in 2009 and Oracle's supported version
> reached
> >> end-of-life in 2015. https://developer.ibm.com/
> javasdk/support/lifecycle/
> >>  doesn’t even
> show
> >> Java 5 any more but https://www.ibm.com/developerworks/community/
> >> forums/html/topic?id=----14807464 <
> >> https://www.ibm.com/developerworks/community/
> >> forums/html/topic?id=----14807464> indicates
> that
> >> it also was dropped in 2015.
> >>
> >> So why are we discussing support for Java 1.5 when not even the vendors
> >> who ship it support it?
> >>
> >> Ralph
> >>
> >>
> >> > On Jun 5, 2017, at 9:45 AM, Gary Gregory 
> wrote:
> >> >
> >> > On Mon, Jun 5, 2017 at 9:17 AM, Jochen Wiedmann <
> >> jochen.wiedm...@gmail.com >
> >> > wrote:
> >> >
> >> >> On Mon, Jun 5, 2017 at 5:20 PM, sebb  wrote:
> >> >>
> >>  I'd like us to be able to push out a new release with minimal
> changes
> >>  at any given time. If we have, for example, 1.6 as the target, and
> the
> >>  previous
> >>  release had 1.5 as the target, then we'd loose that ability, IMO.
> >>  (Think security releases.We've had quite a few in the past.)
> >> >>>
> >> >>> Understood, but I'm not sure why you feel the lack of a 1.6 release
> >> >>> would prevent a security release.
> >> >>> Surely we could just apply the fixes to the previously released code
> >> >>> and change to 1.6 at the same time?
> >> >>
> >> >> Because the result clearly be binary incompatible to its predecessor,
> >> >> and that's the whole point of such an emergency release. We'd want a
> >> >> drop-in replacement.
> >> >>
> >> >
> >> > If someone wants a fix for something that runs on 1.5, they are
> welcome
> >> to
> >> > provide a PR. I do not think we need to handcuff ourselves to Java 5.
> If
> >> > your runtime is stuck on Java 5, your likely to have other more
> pressing
> >> > security issues to address...
> >> >
> >> > Gary
> >> >
> >> >>
> >> >> Jochen
> >> >>
> >> >>
> >> >> --
> >> >> The next time you hear: "Don't reinvent the wheel!"
> >> >>
> >> >> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/ <
> >> 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  >> dev-unsubscr...@commons.apache.org>
> >> >> For additional commands, e-mail: dev-h...@commons.apache.org
>  >> 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: Compiler targets and Java 9

[sebb]

On 5 June 2017 at 20:26, Amey Jadiye  wrote:
> +1
>
> I have seen hundreds of applications which are in (maintenance+ little
> enhancement) mode are already moved to higher versions of java ( >1.5 ),
> even very legacy applications which are just in maintenance mode or marked
> for decommission are already running on 1.6 as all know that there will be
> no updates. there could be rarest of rare applications running on 1.5 and
> sure they dont want move else they could have moved long back to 1.6 and
> and rarely 1.5 will move to java8 or 9 ;)
>
> so yeah, why are we discussing support for Java 1.5 when not even the
> vendors who ship it support it ? just move our modules for >=1.6.

This thread is *not* about support for 1.5.

It's about supporting Java 9, and what to do about components whose
last release is 1.5 or earlier.

That is very different.

> Regards,
> Amey
>
> On Mon, Jun 5, 2017 at 10:24 PM, Ralph Goers 
> wrote:
>
>> This whole discussion has me really confused.  According to
>> https://en.wikipedia.org/wiki/Java_version_history <
>> https://en.wikipedia.org/wiki/Java_version_history> the free version of
>> Java 5 reached end-of-life in 2009 and Oracle's supported version reached
>> end-of-life in 2015. https://developer.ibm.com/javasdk/support/lifecycle/
>>  doesn’t even show
>> Java 5 any more but https://www.ibm.com/developerworks/community/
>> forums/html/topic?id=----14807464 <
>> https://www.ibm.com/developerworks/community/
>> forums/html/topic?id=----14807464> indicates that
>> it also was dropped in 2015.
>>
>> So why are we discussing support for Java 1.5 when not even the vendors
>> who ship it support it?
>>
>> Ralph
>>
>>
>> > On Jun 5, 2017, at 9:45 AM, Gary Gregory  wrote:
>> >
>> > On Mon, Jun 5, 2017 at 9:17 AM, Jochen Wiedmann <
>> jochen.wiedm...@gmail.com >
>> > wrote:
>> >
>> >> On Mon, Jun 5, 2017 at 5:20 PM, sebb  wrote:
>> >>
>>  I'd like us to be able to push out a new release with minimal changes
>>  at any given time. If we have, for example, 1.6 as the target, and the
>>  previous
>>  release had 1.5 as the target, then we'd loose that ability, IMO.
>>  (Think security releases.We've had quite a few in the past.)
>> >>>
>> >>> Understood, but I'm not sure why you feel the lack of a 1.6 release
>> >>> would prevent a security release.
>> >>> Surely we could just apply the fixes to the previously released code
>> >>> and change to 1.6 at the same time?
>> >>
>> >> Because the result clearly be binary incompatible to its predecessor,
>> >> and that's the whole point of such an emergency release. We'd want a
>> >> drop-in replacement.
>> >>
>> >
>> > If someone wants a fix for something that runs on 1.5, they are welcome
>> to
>> > provide a PR. I do not think we need to handcuff ourselves to Java 5. If
>> > your runtime is stuck on Java 5, your likely to have other more pressing
>> > security issues to address...
>> >
>> > Gary
>> >
>> >>
>> >> Jochen
>> >>
>> >>
>> >> --
>> >> The next time you hear: "Don't reinvent the wheel!"
>> >>
>> >> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/ <
>> 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 > dev-unsubscr...@commons.apache.org>
>> >> For additional commands, e-mail: dev-h...@commons.apache.org > 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

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

[Amey Jadiye]

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?

-
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

[Amey Jadiye]

+1

I have seen hundreds of applications which are in (maintenance+ little
enhancement) mode are already moved to higher versions of java ( >1.5 ),
even very legacy applications which are just in maintenance mode or marked
for decommission are already running on 1.6 as all know that there will be
no updates. there could be rarest of rare applications running on 1.5 and
sure they dont want move else they could have moved long back to 1.6 and
and rarely 1.5 will move to java8 or 9 ;)

so yeah, why are we discussing support for Java 1.5 when not even the
vendors who ship it support it ? just move our modules for >=1.6.

Regards,
Amey

On Mon, Jun 5, 2017 at 10:24 PM, Ralph Goers 
wrote:

> This whole discussion has me really confused.  According to
> https://en.wikipedia.org/wiki/Java_version_history <
> https://en.wikipedia.org/wiki/Java_version_history> the free version of
> Java 5 reached end-of-life in 2009 and Oracle's supported version reached
> end-of-life in 2015. https://developer.ibm.com/javasdk/support/lifecycle/
>  doesn’t even show
> Java 5 any more but https://www.ibm.com/developerworks/community/
> forums/html/topic?id=----14807464 <
> https://www.ibm.com/developerworks/community/
> forums/html/topic?id=----14807464> indicates that
> it also was dropped in 2015.
>
> So why are we discussing support for Java 1.5 when not even the vendors
> who ship it support it?
>
> Ralph
>
>
> > On Jun 5, 2017, at 9:45 AM, Gary Gregory  wrote:
> >
> > On Mon, Jun 5, 2017 at 9:17 AM, Jochen Wiedmann <
> jochen.wiedm...@gmail.com >
> > wrote:
> >
> >> On Mon, Jun 5, 2017 at 5:20 PM, sebb  wrote:
> >>
>  I'd like us to be able to push out a new release with minimal changes
>  at any given time. If we have, for example, 1.6 as the target, and the
>  previous
>  release had 1.5 as the target, then we'd loose that ability, IMO.
>  (Think security releases.We've had quite a few in the past.)
> >>>
> >>> Understood, but I'm not sure why you feel the lack of a 1.6 release
> >>> would prevent a security release.
> >>> Surely we could just apply the fixes to the previously released code
> >>> and change to 1.6 at the same time?
> >>
> >> Because the result clearly be binary incompatible to its predecessor,
> >> and that's the whole point of such an emergency release. We'd want a
> >> drop-in replacement.
> >>
> >
> > If someone wants a fix for something that runs on 1.5, they are welcome
> to
> > provide a PR. I do not think we need to handcuff ourselves to Java 5. If
> > your runtime is stuck on Java 5, your likely to have other more pressing
> > security issues to address...
> >
> > Gary
> >
> >>
> >> Jochen
> >>
> >>
> >> --
> >> The next time you hear: "Don't reinvent the wheel!"
> >>
> >> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/ <
> 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  dev-unsubscr...@commons.apache.org>
> >> For additional commands, e-mail: dev-h...@commons.apache.org  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

[Matt Sicker]

I'm confused about one thing here. Sure, you can't use javac in 9 to
compile for 5, but can't java in 9 still run class files compiled against
5? If you couldn't run older java classes anymore, then I don't know why
Oracle continues to maintain backward compatibility in places that are
annoying.

On 5 June 2017 at 11:54, Ralph Goers  wrote:

> This whole discussion has me really confused.  According to
> https://en.wikipedia.org/wiki/Java_version_history <
> https://en.wikipedia.org/wiki/Java_version_history> the free version of
> Java 5 reached end-of-life in 2009 and Oracle's supported version reached
> end-of-life in 2015. https://developer.ibm.com/javasdk/support/lifecycle/
>  doesn’t even show
> Java 5 any more but https://www.ibm.com/developerworks/community/
> forums/html/topic?id=----14807464 <
> https://www.ibm.com/developerworks/community/
> forums/html/topic?id=----14807464> indicates that
> it also was dropped in 2015.
>
> So why are we discussing support for Java 1.5 when not even the vendors
> who ship it support it?
>
> Ralph
>
>
> > On Jun 5, 2017, at 9:45 AM, Gary Gregory  wrote:
> >
> > On Mon, Jun 5, 2017 at 9:17 AM, Jochen Wiedmann <
> jochen.wiedm...@gmail.com >
> > wrote:
> >
> >> On Mon, Jun 5, 2017 at 5:20 PM, sebb  wrote:
> >>
>  I'd like us to be able to push out a new release with minimal changes
>  at any given time. If we have, for example, 1.6 as the target, and the
>  previous
>  release had 1.5 as the target, then we'd loose that ability, IMO.
>  (Think security releases.We've had quite a few in the past.)
> >>>
> >>> Understood, but I'm not sure why you feel the lack of a 1.6 release
> >>> would prevent a security release.
> >>> Surely we could just apply the fixes to the previously released code
> >>> and change to 1.6 at the same time?
> >>
> >> Because the result clearly be binary incompatible to its predecessor,
> >> and that's the whole point of such an emergency release. We'd want a
> >> drop-in replacement.
> >>
> >
> > If someone wants a fix for something that runs on 1.5, they are welcome
> to
> > provide a PR. I do not think we need to handcuff ourselves to Java 5. If
> > your runtime is stuck on Java 5, your likely to have other more pressing
> > security issues to address...
> >
> > Gary
> >
> >>
> >> Jochen
> >>
> >>
> >> --
> >> The next time you hear: "Don't reinvent the wheel!"
> >>
> >> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/ <
> 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  dev-unsubscr...@commons.apache.org>
> >> For additional commands, e-mail: dev-h...@commons.apache.org  dev-h...@commons.apache.org>
>



-- 
Matt Sicker 

[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 @garydgregory , Its already discussed here 
[LANG-564](https://issues.apache.org/jira/browse/LANG-564) and 
[TEXT-80](https://issues.apache.org/jira/browse/TEXT-80) and all seems agree on 
changing the code, according to discussion code proposed in this PR will 
improve the API. 

As this is moved from commons lang, version of  ```StrLookup``` will soon 
be deprecated. so no cross module impact I see for now and yes whoever using 
text 1.0, 1.1 will need to change code very minimal. 


---
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: [all] Deploying components

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



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

Re: Compiler targets and Java 9

[Ralph Goers]

This whole discussion has me really confused.  According to 
https://en.wikipedia.org/wiki/Java_version_history 
 the free version of Java 5 
reached end-of-life in 2009 and Oracle's supported version reached end-of-life 
in 2015. https://developer.ibm.com/javasdk/support/lifecycle/ 
 doesn’t even show Java 5 
any more but 
https://www.ibm.com/developerworks/community/forums/html/topic?id=----14807464
 

 indicates that it also was dropped in 2015.

So why are we discussing support for Java 1.5 when not even the vendors who 
ship it support it?

Ralph


> On Jun 5, 2017, at 9:45 AM, Gary Gregory  wrote:
> 
> On Mon, Jun 5, 2017 at 9:17 AM, Jochen Wiedmann  >
> wrote:
> 
>> On Mon, Jun 5, 2017 at 5:20 PM, sebb  wrote:
>> 
 I'd like us to be able to push out a new release with minimal changes
 at any given time. If we have, for example, 1.6 as the target, and the
 previous
 release had 1.5 as the target, then we'd loose that ability, IMO.
 (Think security releases.We've had quite a few in the past.)
>>> 
>>> Understood, but I'm not sure why you feel the lack of a 1.6 release
>>> would prevent a security release.
>>> Surely we could just apply the fixes to the previously released code
>>> and change to 1.6 at the same time?
>> 
>> Because the result clearly be binary incompatible to its predecessor,
>> and that's the whole point of such an emergency release. We'd want a
>> drop-in replacement.
>> 
> 
> If someone wants a fix for something that runs on 1.5, they are welcome to
> provide a PR. I do not think we need to handcuff ourselves to Java 5. If
> your runtime is stuck on Java 5, your likely to have other more pressing
> security issues to address...
> 
> Gary
> 
>> 
>> Jochen
>> 
>> 
>> --
>> 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 
>> 

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

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

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: Compiler targets and Java 9

[Gary Gregory]

On Mon, Jun 5, 2017 at 9:17 AM, Jochen Wiedmann 
wrote:

> On Mon, Jun 5, 2017 at 5:20 PM, sebb  wrote:
>
> >> I'd like us to be able to push out a new release with minimal changes
> >> at any given time. If we have, for example, 1.6 as the target, and the
> >> previous
> >> release had 1.5 as the target, then we'd loose that ability, IMO.
> >> (Think security releases.We've had quite a few in the past.)
> >
> > Understood, but I'm not sure why you feel the lack of a 1.6 release
> > would prevent a security release.
> > Surely we could just apply the fixes to the previously released code
> > and change to 1.6 at the same time?
>
> Because the result clearly be binary incompatible to its predecessor,
> and that's the whole point of such an emergency release. We'd want a
> drop-in replacement.
>

If someone wants a fix for something that runs on 1.5, they are welcome to
provide a PR. I do not think we need to handcuff ourselves to Java 5. If
your runtime is stuck on Java 5, your likely to have other more pressing
security issues to address...

Gary

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

Re: Compiler targets and Java 9

[Gary Gregory]

On Mon, Jun 5, 2017 at 8:20 AM, sebb  wrote:

> On 5 June 2017 at 16:09, Jochen Wiedmann 
> wrote:
> > On Mon, Jun 5, 2017 at 5:06 PM, sebb  wrote:
> >
> >>> I'd like us to push out a new release with minimal changes at any
> >>> time. If we have, for example, 1.6 as the target, and the previous
> >>> release had 1.5 as the target, then we'd loose that ability, IMO.
> >>
> >> Sorry, I don't follow.
> >> Are there some missing words from the above?
> >
> > Indeed there are. So, to repeat that:
> >
> > I'd like us to be able to push out a new release with minimal changes
> > at any given time. If we have, for example, 1.6 as the target, and the
> > previous
> > release had 1.5 as the target, then we'd loose that ability, IMO.
> > (Think security releases.We've had quite a few in the past.)
>
> Understood, but I'm not sure why you feel the lack of a 1.6 release
> would prevent a security release.
> Surely we could just apply the fixes to the previously released code
> and change to 1.6 at the same time?
>

+1

Gary

>
> Or would there need to be fixes to the code just to update to 1.6?
> In which case releasing a 1.6 would ensure those were fixed at our
> leisure instead of having to be fixed as part of a rush to release
> security patch.
> Is that what you mean?
>
> > Jochen
> >
> >
> >
> > --
> > 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
>
>

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

[garydgregory]

Github user garydgregory commented on the issue:

https://github.com/apache/commons-text/pull/44
  
BTW, this will break source compatibility for certain.


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

[garydgregory]

Github user garydgregory commented on the issue:

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

Why is it confusing? Why is the patch better? You get the idea, you have to 
make a point that what you propose is better beyond changing source.

Gary


---
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: Compiler targets and Java 9

[sebb]

On 5 June 2017 at 17:17, Jochen Wiedmann  wrote:
> On Mon, Jun 5, 2017 at 5:20 PM, sebb  wrote:
>
>>> I'd like us to be able to push out a new release with minimal changes
>>> at any given time. If we have, for example, 1.6 as the target, and the
>>> previous
>>> release had 1.5 as the target, then we'd loose that ability, IMO.
>>> (Think security releases.We've had quite a few in the past.)
>>
>> Understood, but I'm not sure why you feel the lack of a 1.6 release
>> would prevent a security release.
>> Surely we could just apply the fixes to the previously released code
>> and change to 1.6 at the same time?
>
> Because the result clearly be binary incompatible to its predecessor,
> and that's the whole point of such an emergency release. We'd want a
> drop-in replacement.

It would not be a drop-in replacement for systems running Java 1.5,
but surely it would be compatible for those running 1.6?
If they are still running 1.5, the release would be no use anyway.

I agree that we should ideally release 1.6 to make it quicker to
release an emergency fix (and to help those stuck with 1.9+).
I'm just trying to understand your reasoning.

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

[Jochen Wiedmann]

On Mon, Jun 5, 2017 at 5:20 PM, sebb  wrote:

>> I'd like us to be able to push out a new release with minimal changes
>> at any given time. If we have, for example, 1.6 as the target, and the
>> previous
>> release had 1.5 as the target, then we'd loose that ability, IMO.
>> (Think security releases.We've had quite a few in the past.)
>
> Understood, but I'm not sure why you feel the lack of a 1.6 release
> would prevent a security release.
> Surely we could just apply the fixes to the previously released code
> and change to 1.6 at the same time?

Because the result clearly be binary incompatible to its predecessor,
and that's the whole point of such an emergency release. We'd want a
drop-in replacement.

Jochen


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

Re: Compiler targets and Java 9

[sebb]

On 5 June 2017 at 16:09, Jochen Wiedmann  wrote:
> On Mon, Jun 5, 2017 at 5:06 PM, sebb  wrote:
>
>>> I'd like us to push out a new release with minimal changes at any
>>> time. If we have, for example, 1.6 as the target, and the previous
>>> release had 1.5 as the target, then we'd loose that ability, IMO.
>>
>> Sorry, I don't follow.
>> Are there some missing words from the above?
>
> Indeed there are. So, to repeat that:
>
> I'd like us to be able to push out a new release with minimal changes
> at any given time. If we have, for example, 1.6 as the target, and the
> previous
> release had 1.5 as the target, then we'd loose that ability, IMO.
> (Think security releases.We've had quite a few in the past.)

Understood, but I'm not sure why you feel the lack of a 1.6 release
would prevent a security release.
Surely we could just apply the fixes to the previously released code
and change to 1.6 at the same time?

Or would there need to be fixes to the code just to update to 1.6?
In which case releasing a 1.6 would ensure those were fixed at our
leisure instead of having to be fixed as part of a rush to release
security patch.
Is that what you mean?

> Jochen
>
>
>
> --
> 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: [VOTE][LAZY] Migrate Apache Commons CLI to git

[Gary Gregory]

+1

Gary

On Jun 5, 2017 4:20 AM, "Benedikt Ritter"  wrote:

> 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.
>
> Regards,
> Benedikt
>
>
> -
> 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 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: Compiler targets and Java 9

[Jochen Wiedmann]

On Mon, Jun 5, 2017 at 5:06 PM, sebb  wrote:

>> I'd like us to push out a new release with minimal changes at any
>> time. If we have, for example, 1.6 as the target, and the previous
>> release had 1.5 as the target, then we'd loose that ability, IMO.
>
> Sorry, I don't follow.
> Are there some missing words from the above?

Indeed there are. So, to repeat that:

I'd like us to be able to push out a new release with minimal changes
at any given time. If we have, for example, 1.6 as the target, and the
previous
release had 1.5 as the target, then we'd loose that ability, IMO.
(Think security releases.We've had quite a few in the past.)

Jochen



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

Re: Compiler targets and Java 9

[sebb]

On 5 June 2017 at 15:54, Jochen Wiedmann  wrote:
> On Mon, Jun 5, 2017 at 4:50 PM, Emmanuel Bourg  wrote:
>
>> +1 for using 1.6 as the baseline, but I don't see the need to publish
>> new releases with that target if nothing else changed.

+1 for 1.6

If we don't release, then we can only change the pom in trunk.
We should not encourage ordinary users to build from trunk.
Which would mean that the software would not be buildable using Java 9.

>
> I'd like us to push out a new release with minimal changes at any
> time. If we have, for example, 1.6 as the target, and the previous
> release had 1.5 as the target, then we'd loose that ability, IMO.

Sorry, I don't follow.
Are there some missing words from the above?

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

[sebb]

On 5 June 2017 at 12:06, Benedikt Ritter  wrote:
> Hello Rob,
>
>> Am 28.05.2017 um 03:01 schrieb Rob Tompkins :
>>
>> 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
>>  
>> 
>>
>> 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.
>
> Nice catch, however I alway run clean when deploying, since I don’t want 
> stale build artifacts to be deployed (this happened to me once).

Unfortunately that may not be sufficient, as it won't remove spurious
source files.

It's best to checkout the tag in a clean directory and build from there.

IMO that is what the release plugin should do, however instead it
updates the trunk version and builds from the 'unclean' workspace.
If the RC fails, then trunk has to be backdated.
Meanwhile any CI builds will have picked up the new SNAPSHOT version.

The release plugin should assume that the RC may fail, and not update
trunk until the release process succeeds.

> I’m planning to ask the maven user list on how we can improve our deployment 
> process.

They are unlikely to accept that the release plugin has limitations ...

> Regards,
> Benedikt
>
>>
>> Cheers,
>> -Rob
>
>
> -
> 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

[Jochen Wiedmann]

On Mon, Jun 5, 2017 at 4:50 PM, Emmanuel Bourg  wrote:

> +1 for using 1.6 as the baseline, but I don't see the need to publish
> new releases with that target if nothing else changed.

I'd like us to push out a new release with minimal changes at any
time. If we have, for example, 1.6 as the target, and the previous
release had 1.5 as the target, then we'd loose that ability, IMO.

Jochen



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

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

[Matt Sicker]

>From what I recall, the IBM JDK is only for Linux and Windows.

On 5 June 2017 at 05:54, Benedikt Ritter  wrote:

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

Re: Compiler targets and Java 9

[Emmanuel Bourg]

Le 5/06/2017 à 16:41, Jochen Wiedmann a écrit :

> 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 for using 1.6 as the baseline, but I don't see the need to publish
new releases with that target if nothing else changed.

Emmanuel Bourg


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

Compiler targets and Java 9

[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.

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

Re: [VOTE][LAZY] Migrate Apache Commons CLI to git

[Amey Jadiye]

Ah .. Thanks for the knowledge, got confused with this url git://
git.apache.org/commons-cli.git

+1 for migration.

Regards,
Amey


On Mon, Jun 5, 2017, 7:16 PM Rob Tompkins  wrote:

>
> > On Jun 5, 2017, at 9:39 AM, Amey Jadiye  wrote:
> >
> > Hi,
> >
> > I already see it's on github [1] which is mirror of Apache repository
> [2].
> > Is my understanding correct or am I missing something here ?
> >
> >
> > [1] https://github.com/apache/commons-cli
> > [2] git://git.apache.org/commons-cli.git  git.apache.org/commons-cli.git>
>
> Hi Amey,
>
> Give a look here: http://git.apache.org 
>
> They can mirror either SVN or GIT at apache out to GitHub. [cli] looks to
> be git-mirrored off the SVN repo.
>
> -Rob
>
> >
> > Regards,
> > Amey
> >
> > On Mon, Jun 5, 2017, 4:50 PM Benedikt Ritter  wrote:
> >
> >> 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.
> >>
> >> Regards,
> >> Benedikt
> >>
> >>
> >> -
> >> 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 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.

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

Re: [TEXT]: No Github to commons-dev ML connectivity.

[Rob Tompkins]

> On Jun 5, 2017, at 4:48 AM, Benedikt Ritter  wrote:
> 
> Hi,
> 
>> Am 02.06.2017 um 21:44 schrieb Amey Jadiye :
>> 
>> Hi,
>> 
>> I have observed many mails from commons lang,  fileupload, cli, compress
>> and many other modules where if someone opened PR or commented on it a copy
>> of activity comes to ML, but same doesn't happens for commons-text can we
>> please setup same for commons-text also check if any other module need it?
> 
> I’ve create INFRA-14828 [1] to make it happen.

Thanks Benedikt. I was going to get around to that, but you beat me to it.

-Rob

> 
> Thank you,
> Benedikt
> 
> [1] https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-14282
> 
>> 
>> Regards,
>> Amey
>> 
>> -
>> 
>> 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][LAZY] Migrate Apache Commons CLI to git

[Rob Tompkins]

> On Jun 5, 2017, at 9:39 AM, Amey Jadiye  wrote:
> 
> Hi,
> 
> I already see it's on github [1] which is mirror of Apache repository [2].
> Is my understanding correct or am I missing something here ?
> 
> 
> [1] https://github.com/apache/commons-cli
> [2] git://git.apache.org/commons-cli.git 
> 

Hi Amey,

Give a look here: http://git.apache.org 

They can mirror either SVN or GIT at apache out to GitHub. [cli] looks to be 
git-mirrored off the SVN repo.

-Rob

> 
> Regards,
> Amey
> 
> On Mon, Jun 5, 2017, 4:50 PM Benedikt Ritter  wrote:
> 
>> 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.
>> 
>> Regards,
>> Benedikt
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 

[GitHub] commons-text pull request #43: [Junit]: Added test cases for CsvTranslators

[asfgit]

Github user asfgit closed the pull request at:

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


---
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
  
Would this imply a 2.0 release because of BC compatibility?


---
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][LAZY] Migrate Apache Commons CLI to git

[Amey Jadiye]

Hi,

I already see it's on github [1] which is mirror of Apache repository [2].
Is my understanding correct or am I missing something here ?


[1] https://github.com/apache/commons-cli
[2] git://git.apache.org/commons-cli.git

Regards,
Amey

On Mon, Jun 5, 2017, 4:50 PM Benedikt Ritter  wrote:

> 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.
>
> Regards,
> Benedikt
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [all] Deploying components

[Rob Tompkins]

> On Jun 5, 2017, at 7:06 AM, Benedikt Ritter  wrote:
> 
> Hello Rob,
> 
>> Am 28.05.2017 um 03:01 schrieb Rob Tompkins :
>> 
>> 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
>>  
>> 
>> 
>> 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.
> 
> Nice catch, however I alway run clean when deploying, since I don’t want 
> stale build artifacts to be deployed (this happened to me once).
> 
> I’m planning to ask the maven user list on how we can improve our deployment 
> process.

Sounds good to me. I was going to play around with the commons-build-plugin to 
see what I could do with that.

> 
> Regards,
> Benedikt
> 
>> 
>> Cheers,
>> -Rob
> 
> 
> -
> 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][LAZY] Migrate Apache Commons CLI to git

[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.

Regards,
Benedikt


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

Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

[Amey Jadiye]

+1

I like the way of implementation, I think we should have class in Commons
text CaseUtils.toCamelCase(String str, char delimiter, boolean
capitalizeFirstLetter)
Also this can have api for snake case (not sure if java need it)

@chtompki , If you wish I will submit code for review.

Regards,
Amey

On Jun 5, 2017 3:45 PM, "Benedikt Ritter"  wrote:

> Hi,
>
> > Am 01.06.2017 um 16:03 schrieb Rob Tompkins :
> >
> > Hello all,
> >
> > Folks at my day job have a method that takes in a space delimited String
> (or arbitrarily delimited string for that matter), and returns a camel
> cased string. Is there any reason that this shouldn’t be in StringUtils? It
> feels reasonable to me. What are folks thoughts?
>
> Sorry to come late to this discussion. We should have a look at Guava’s
> CaseFormat class, which das camel case conversion and more. I think that
> design should lead yours.
> I’ve come to the conclusion that anything that is more complex than
> StringUtils.isEmpty(String) (e.g. needs more than one parameter) should not
> be implemented as a static util method. Such a design always leads to
> procedural style coding which is an anti pattern IMHO.
> CaseFormat is a nice example of how should an API can be build more OOP
> style.
>
> Regards,
> Benedikt
>
> >
> > Cheers,
> > -Rob
> > -
> > 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 Rob,

> Am 28.05.2017 um 03:01 schrieb Rob Tompkins :
> 
> 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 
> 
> 
> 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.

Nice catch, however I alway run clean when deploying, since I don’t want stale 
build artifacts to be deployed (this happened to me once).

I’m planning to ask the maven user list on how we can improve our deployment 
process.

Regards,
Benedikt

> 
> Cheers,
> -Rob


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

[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,

> 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(ParentRunner.java:290)
> 
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 
> at 

[LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

[Benedikt Ritter]

> Am 25.05.2017 um 18:23 schrieb Oliver Heger :
> 
> 
> 
> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>> On 23 May 2017 at 17:17, sebb  wrote:
 Yes, the
 code compiles and both can be on the classpath, but it is a pain to
 use, just a different kind of hell.
>>> 
>>> I don't see what the problem is here.
>> 
>> Library A that depends on lang3 returns a Pair.
>> Library B that depends on lang4 takes a Pair.
>> Application cannot pass Pair from A to the B without conversion.
>> 
>> My point is that it is possible to over-worry about jar hell.
>> Joda-Time removed some methods when it went from v1.x to v2.x, but
>> didn't change package name or maven co-ordinates. It was far more
>> important that end-users didn't have two different LocalDate classes
>> (a problem that couldn't be avoided when moving to Java 8). I've never
>> seen any feedback about the incompatibility causing jar hell.
>> 
>> The same is true here. It is vital to think properly about which is
>> the worse choice, not just assume that jar hell must always be
>> avoided.
>> 
>> I remain completely unconvinced that removing these two problematic
>> methods justifies the lang4 package name, forcing end-users to have
>> three copies of the library on the classpath. It should need much,
>> much more to justify lang4 package name. In fact I've yet to hear
>> anything else much in this thread that justifies a major release.
> 
> I also think that a new major release just to fix this problem would be
> overkill and cause clients even more trouble.
> 
> Would the following approach work as a compromise:
> 
> - [lang] declares an optional dependency to the desktop module.
> - All affected classes (AbstractCircuitBreaker and its two sub classes)
> are marked as deprecated.
> - Copies are created from the original classes with slightly changed
> names or in a new package (tbd). These copies use a new change listener
> mechanism.
> 
> IIUC, the resulting [lang] module can now be used without the dependency
> to desktop when the new classes are used. The dependency will only be
> needed for the deprecated versions.

Let’s do it like this. Sounds like the right way to me.

Benedikt

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

Re: [ALL] Video recordings of Apache Commons presentations at ApacheCON 2017 in Miami

[Benedikt Ritter]

Hi,

> Am 26.05.2017 um 08:17 schrieb Gary Gregory :
> 
> Hi All,
> 
> These talks are great; well done guys! I encourage all to watch :-)

And I encourage all to join as at the next ApacheCON :-)

> 
> Gary
> 
> On Sun, May 21, 2017 at 4:40 PM, Benedikt Ritter  wrote:
> 
>> Hi,
>> 
>> at this year’s ApacheCON we had some nice presentations. I’d like to share
>> the video recordings with you (in order they were held at the event)
>> 
>> Apache Commons - State of the Union by myself:
>> https://www.youtube.com/watch?v=dejxS9qkfMc=5=
>> PLbzoR-pLrL6pLDCyPxByWQwYTL-JrF5Rp > watch?v=dejxS9qkfMc=5=PLbzoR-pLrL6pLDCyPxByWQwYTL-JrF5Rp>
>> 
>> Apache Commons Crypto: Another wheel of Apache Commons by Dapeng Sun:
>> https://www.youtube.com/watch?v=Vwp8oHnut3k=6=
>> PLbzoR-pLrL6pLDCyPxByWQwYTL-JrF5Rp > watch?v=Vwp8oHnut3k=6=PLbzoR-pLrL6pLDCyPxByWQwYTL-JrF5Rp>
>> 
>> Introducing Apache Commons Text by Rob Tompkins:
>> https://www.youtube.com/watch?v=rqBJHpQ5yvo=PLbzoR-
>> pLrL6pLDCyPxByWQwYTL-JrF5Rp=9 > watch?v=rqBJHpQ5yvo=PLbzoR-pLrL6pLDCyPxByWQwYTL-JrF5Rp=9>
>> 
>> Apache Commons - Beyond StringUtils by myself:
>> https://www.youtube.com/watch?v=eZB3P5VVIuc=PLbzoR-
>> pLrL6pLDCyPxByWQwYTL-JrF5Rp=8 > watch?v=eZB3P5VVIuc=PLbzoR-pLrL6pLDCyPxByWQwYTL-JrF5Rp=8>
>> 
>> It was great meeting with other Commons committers. We had a great time.
>> I’m looking forward to the next ApacheCON, where I hope to meet more of you
>> in person.
>> 
>> Regards,
>> Benedikt
> 
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> 
> 
> JUnit in Action, Second Edition
> 
> 
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory


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

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

[Benedikt Ritter]

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

[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
  
LGTM, @chtompki what do you think?


---
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
  
@britter , please review and accept this PR. Travis build on this is 
because previous commit in master , by merging this won't make any issue in 
master. Tested on local before creating PR.

With this comment we can test if activity goes to dev ml.


---
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: [TEXT]: No Github to commons-dev ML connectivity.

[Benedikt Ritter]

Hello Amey,

> Am 05.06.2017 um 12:20 schrieb Amey Jadiye :
> 
> Thanks for the help Benedikt.

The issue has just been resolved by infra. So the notifications should be 
working now.

Regards,
Benedikt

> 
> Regards,
> Amey
> 
> 
> On Jun 5, 2017 2:18 PM, "Benedikt Ritter"  wrote:
> 
> Hi,
> 
>> Am 02.06.2017 um 21:44 schrieb Amey Jadiye :
>> 
>> Hi,
>> 
>> I have observed many mails from commons lang,  fileupload, cli, compress
>> and many other modules where if someone opened PR or commented on it a
> copy
>> of activity comes to ML, but same doesn't happens for commons-text can we
>> please setup same for commons-text also check if any other module need it?
> 
> I’ve create INFRA-14828 [1] to make it happen.
> 
> Thank you,
> Benedikt
> 
> [1] https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-14282
> 
>> 
>> Regards,
>> Amey
>> 
>> -
>> 
>> 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: [TEXT]: No Github to commons-dev ML connectivity.

[Amey Jadiye]

Thanks for the help Benedikt.

Regards,
Amey


On Jun 5, 2017 2:18 PM, "Benedikt Ritter"  wrote:

Hi,

> Am 02.06.2017 um 21:44 schrieb Amey Jadiye :
>
> Hi,
>
> I have observed many mails from commons lang,  fileupload, cli, compress
> and many other modules where if someone opened PR or commented on it a
copy
> of activity comes to ML, but same doesn't happens for commons-text can we
> please setup same for commons-text also check if any other module need it?

I’ve create INFRA-14828 [1] to make it happen.

Thank you,
Benedikt

[1] https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-14282

>
> Regards,
> Amey
>
> -
>
> 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?

[Benedikt Ritter]

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.

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

Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

[Benedikt Ritter]

Hi,

> Am 01.06.2017 um 16:03 schrieb Rob Tompkins :
> 
> Hello all,
> 
> Folks at my day job have a method that takes in a space delimited String (or 
> arbitrarily delimited string for that matter), and returns a camel cased 
> string. Is there any reason that this shouldn’t be in StringUtils? It feels 
> reasonable to me. What are folks thoughts?

Sorry to come late to this discussion. We should have a look at Guava’s 
CaseFormat class, which das camel case conversion and more. I think that design 
should lead yours. 
I’ve come to the conclusion that anything that is more complex than 
StringUtils.isEmpty(String) (e.g. needs more than one parameter) should not be 
implemented as a static util method. Such a design always leads to procedural 
style coding which is an anti pattern IMHO.
CaseFormat is a nice example of how should an API can be build more OOP style.

Regards,
Benedikt

> 
> Cheers,
> -Rob
> -
> 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

[Stephen Colebourne]

On 5 June 2017 at 09:35, Benedikt Ritter  wrote:
> Is there some documentation on how to check validity?

I'm sure there is info in various places, but I've not seen a checklist.

Off the top of my head:
- all packages under a single super-package that is the module name
- jdeps shows no use of internal APIs in the JDK
- no circular dependencies

Once Java 9 is out properly, we can start adding module-info.java
files and creating some proper dependencies.

Stephen

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

Re: [TEXT]: No Github to commons-dev ML connectivity.

[Benedikt Ritter]

Hi,

> Am 02.06.2017 um 21:44 schrieb Amey Jadiye :
> 
> Hi,
> 
> I have observed many mails from commons lang,  fileupload, cli, compress
> and many other modules where if someone opened PR or commented on it a copy
> of activity comes to ML, but same doesn't happens for commons-text can we
> please setup same for commons-text also check if any other module need it?

I’ve create INFRA-14828 [1] to make it happen.

Thank you,
Benedikt

[1] https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-14282

> 
> Regards,
> Amey
> 
> -
> 
> 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: svn commit: r1797520 - /commons/proper/weaver/trunk/pom.xml

[Benedikt Ritter]

Hello Rob,

> Am 03.06.2017 um 18:52 schrieb chtom...@apache.org:
> 
> Author: chtompki
> Date: Sat Jun  3 16:52:58 2017
> New Revision: 1797520
> 
> URL: http://svn.apache.org/viewvc?rev=1797520=rev
> Log:
> (chore) adding commons.module.name to pom
> 
> Modified:
>commons/proper/weaver/trunk/pom.xml
> 
> Modified: commons/proper/weaver/trunk/pom.xml
> URL: 
> http://svn.apache.org/viewvc/commons/proper/weaver/trunk/pom.xml?rev=1797520=1797519=1797520=diff
> ==
> --- commons/proper/weaver/trunk/pom.xml (original)
> +++ commons/proper/weaver/trunk/pom.xml Sat Jun  3 16:52:58 2017
> @@ -48,6 +48,7 @@ under the License.
> UTF-8
> 
> weaver
> +org.apache.commons.weaver

This change has no effect if we don’t add the required configuration of the 
maven-jar-plugin in parent pom.

Regards,
Benedikt

> 1.3
> 
> commons-weaver-${commons.release.version}
> RC2
> 
> 


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

Hello Stephen,

> Am 24.05.2017 um 17:11 schrieb Stephen Colebourne :
> 
> 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.

Is there some documentation on how to check validity?

Regards,
Benedikt

> 
> 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.
> 
> 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},
> 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.
> 
> 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

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

[Benedikt Ritter]

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.

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