[GitHub] commons-lang issue #261: LANG-1317: Add findAnnotation and findMethodsWithAn...

2017-04-02 Thread PascalSchumacher
Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/261
  
Concerning the coverage: I think it's because the coverage differs between 
java versions. The build used to determine coverage depends on the order in 
which the travis builds finish.


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


[jira] [Commented] (LANG-1317) Add findAnnotation and findMethodsWithAnnotation to MethodUtils

2017-04-02 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952636#comment-15952636
 ] 

ASF GitHub Bot commented on LANG-1317:
--

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/261
  
Concerning the coverage: I think it's because the coverage differs between 
java versions. The build used to determine coverage depends on the order in 
which the travis builds finish.


> Add findAnnotation and findMethodsWithAnnotation to MethodUtils
> ---
>
> Key: LANG-1317
> URL: https://issues.apache.org/jira/browse/LANG-1317
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.reflect.*
>Reporter: Yasser Zamani
>  Labels: patch
>
> In order to fix WW-4744 , mainly, I am going to add two functionalities to 
> MethodUtils: findAnnotation and findMethodsWithAnnotation.
> findAnnotation will be an extension for Method.getAnnotation that also 
> searches interfaces and super classes while caching results with no memory 
> leak.
> findMethodsWithAnnotation will be an extension for getMethodsWithAnnotation 
> that also supports non public methods, super class and interface methods, 
> again, while caching results as above.
> Generally, do you agree with these in a pull request? If so, I will be 
> working on it :) 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (MATH-1406) official support for compiling on GWT 2.8

2017-04-02 Thread Michael Borcherds (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952826#comment-15952826
 ] 

Michael Borcherds commented on MATH-1406:
-

Just tried RNG 1.0, it already compiles fine with GWT 2.8.0 (no problems with 
FastMath, ClassCastException or clone())

The 3 major changes needed to apache math are:
* remove reliance on ClassCastException (obvious and uncontroversial)
* remove FastMath and rely on native implementations (less code to maintain so 
also good in my view) 
* add implementations to replace clone() everywhere (a bit boring to do, would 
need testing)

I'm able and willing to help with any of that, just decide what you would like 
:)

> official support for compiling on GWT 2.8
> -
>
> Key: MATH-1406
> URL: https://issues.apache.org/jira/browse/MATH-1406
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Michael Borcherds
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Context: at the moment Apache Commons Math can't be compiled using GWT (to 
> allow it to be made into a JavaScript library for example)
> http://www.gwtproject.org/
> Is there any interest in allowing Apache Commons Math to be officially 
> supported on GWT?
> With GWT 2.8.0 the changes needed aren't too hard to get most of it to compile
> You can see the diff from 3.6.1 here:
> https://github.com/murkle/commons-math/issues/1



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (CODEC-233) Soundex should support more algorithm variants

2017-04-02 Thread Sebb (JIRA)

 [ 
https://issues.apache.org/jira/browse/CODEC-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved CODEC-233.

   Resolution: Fixed
Fix Version/s: 1.11

The special case processing of HW can be overridden in a new constructor and/or 
the presence of any SILENT code characters. This avoids needing to add a 
spurious mapping char.

URL: http://svn.apache.org/viewvc?rev=1789911&view=rev
Log:
CODEC-233 Soundex should support more algorithm variants

Modified:
commons/proper/codec/trunk/src/changes/changes.xml

commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/language/Soundex.java

commons/proper/codec/trunk/src/test/java/org/apache/commons/codec/language/SoundexTest.java


> Soundex should support more algorithm variants
> --
>
> Key: CODEC-233
> URL: https://issues.apache.org/jira/browse/CODEC-233
> Project: Commons Codec
>  Issue Type: New Feature
>Reporter: Sebb
> Fix For: 1.11
>
>
> The existing Soundex class was designed around the American Soundex algorithm.
> Whilst it offers some flexibility with the mapping of letters to Soundex 
> numbers, the list of the 'silent' letters H and W is built-in to the code. 
> There is no provision for changing the set of silent (ignored) letters.
> There is also no way to change the designation of HW from silent into 
> consonant separator - i.e. code 0 - because that is how HW are currently 
> encoded in the public API.
> To fix this, the mapping can be enhanced to support an extra code for 
> 'silent' letters.
> A mapping which includes such a code did not have defined behaviour 
> previously, so can be treated differently - there is no need to assume HW are 
> silent.
> This allows for the definition of alternative silent letters.
> It can also be used to map HW as code '0' - as long as there is at least one 
> 'silent' code. 
> If there are no actual silent letters in the algorithm variant, then the code 
> can be appended to the end of the mapping. This will not affect processing as 
> only letters A-Z are passed to the method. 
> An alternative would be to introduce yet another code as an alias for '0', 
> and only treat HW as silent if they have code '0'.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (MATH-1406) official support for compiling on GWT 2.8

2017-04-02 Thread Gilles (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952877#comment-15952877
 ] 

Gilles commented on MATH-1406:
--

bq. remove reliance on ClassCastException (obvious and uncontroversial)

Are your referring to using exceptions for control flow?
If so, I agree.

bq. remove FastMath

Is FastMath preventing the goal of this issue
Anyways, it must certainly be a separate issue (to be linked to this one), to 
be raised on the "dev" ML.

bq. less code to maintain so also good in my view

Sure, but FastMath (perhaps not well named) is also supposed to give more 
accurate results.
It should be assessed whether it is still the case.

bq. replace clone() everywhere

This is not obvious for me, sorry. In which way is "clone" a problem? Can you 
please provide a concrete example?
In CM, the majority of uses is to duplicate an array.
I'm wary of the _public_ "Cloner" class; at first sight, I'd think that it is 
better to define _private_ methods wherever needed.

bq. I'm able and willing to help with any of that

Thanks.

bq. just decide what you would like

If it were that simple ;)
Please do start a discussion of the "dev" ML; examples of what _you_ want to 
achieve will be welcome (I'm not a JavaScript programmer!).


> official support for compiling on GWT 2.8
> -
>
> Key: MATH-1406
> URL: https://issues.apache.org/jira/browse/MATH-1406
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Michael Borcherds
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Context: at the moment Apache Commons Math can't be compiled using GWT (to 
> allow it to be made into a JavaScript library for example)
> http://www.gwtproject.org/
> Is there any interest in allowing Apache Commons Math to be officially 
> supported on GWT?
> With GWT 2.8.0 the changes needed aren't too hard to get most of it to compile
> You can see the diff from 3.6.1 here:
> https://github.com/murkle/commons-math/issues/1



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (MATH-1406) official support for compiling on GWT 2.8

2017-04-02 Thread Gilles (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952883#comment-15952883
 ] 

Gilles commented on MATH-1406:
--

bq. Just tried RNG 1.0, it already compiles fine with GWT 2.8.0

Good news!
In line with my last comment above, would you be willing to create a short 
example of how the Commons RNG library can be used in a JavaScript program?  It 
sounds like an interesting addition to the "commons-rng-examples" module 
(should be the subject of a JIRA report on said project).


> official support for compiling on GWT 2.8
> -
>
> Key: MATH-1406
> URL: https://issues.apache.org/jira/browse/MATH-1406
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Michael Borcherds
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Context: at the moment Apache Commons Math can't be compiled using GWT (to 
> allow it to be made into a JavaScript library for example)
> http://www.gwtproject.org/
> Is there any interest in allowing Apache Commons Math to be officially 
> supported on GWT?
> With GWT 2.8.0 the changes needed aren't too hard to get most of it to compile
> You can see the diff from 3.6.1 here:
> https://github.com/murkle/commons-math/issues/1



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)