Re: commons-io git repository write access

[Benedikt Ritter]

Hi,

Pascal Schumacher  schrieb am So., 6. Nov. 2016
um 10:49 Uhr:

> Are you sure this works for commons-io?
>
> I tried a configuration similar to commons-lang, but get:
>
> "remote: You are not authorized to edit this repository."
>

I've heart something like this from a fellow ASF committer who wanted to
start contributing to [crypto]. Maybe the permissions are still not set up
correctly on our git repos.

@Pascal, can you file an issue for INFRA for this? All our git repos should
be writable for all ASF committers.

Thank you!
Benedikt


>
> Am 05.11.2016 um 23:54 schrieb Gary Gregory:
> > Nothing if you are an Apache committer already, you have karma
> > automatically.
> >
> > Gary
> >
> > On Nov 5, 2016 2:43 PM, "Pascal Schumacher" 
> > wrote:
> >
> >> Hello everybody,
> >>
> >> if nobody objects I would like to help maintaining commons-io.
> >>
> >> What would I have to do in order to get write access to the git
> repository?
> >>
> >> -Pascal
> >>
> >>
> >> -
> >> 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,Lang] Moving code into commons-text

[Benedikt Ritter]

Hello Rob,

Rob Tompkins  schrieb am So., 6. Nov. 2016 um 17:20 Uhr:

> Hi,
>
> I’ve heard of some intent to get the text functionality out of Lang in the
> long term future and am thinking about starting to chip away at doing this.
> It seems that minimally moving over “org.apache.commons.lang3.text" would
> be a start. Does anyone have any thoughts about what else might migrate
> from Lang into Text?
>

Sorry for being very quite recently. You plan sounds awesome. I hope to
have some time to work on commons again in the next weeks. End of the year
is always busy :-)

Regards and keep up the good work,
Benedikt


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

Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers

[Timo]

Looks like Bill Pugh was woken up:
https://twitter.com/wpugh/status/795350364291813376

2016-11-06 19:00 GMT+01:00 Gary Gregory :

> The whole post is interesting. Sounds like a fork is inevitable. So much
> work though...
>
> Gary
>
> On Nov 6, 2016 9:32 AM, "Stian Soiland-Reyes"  wrote:
>
> > See
> > https://mailman.cs.umd.edu/pipermail/findbugs-discuss/
> > 2016-November/004321.html
> >
> > In particular the author is not happy about the BCEL integration:
> >
> > > The other major reasons for the FindBugs current bad state:
> > >
> > > 1) The code is very complex, has "organically grown" over a decade, is
> > > not documented and has poor public interfaces. Most of the code
> consists
> > > of the very low level bytecode related stuff, tightly coupled with the
> > > ancient BCEL library, which doesn't scale and is not multi-thread safe.
> > > No one enjoys maintaining this code, at least not me. I see no future
> > > for FindBugs with the BCEL approach, and see no way to get rid of it
> > > without investing lot of effort, and without breaking every detector
> and
> > > possibly many 3rd party tools. This is the biggest issue we have with
> > > FindBugs today, and most likely the root cause for all the evil. This
> > > code can't be fixed, it must be rewritten.
> >
> > ..but the main problem seems to be lack of maintaners.
> >
> >
> > --
> > Stian Soiland-Reyes
> > http://orcid.org/-0001-9842-9718
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [TEXT] TEXT-10 A more complex Levenshtein distance

[don jeba]

Hi Bruno,The existing array with name "d", at any given instance contains data 
meant for only one row in the matrix.My understanding to get the number of 
inserts, deletes and substitutes, we need to form the complete matrix and 
iterate the diagonal elements to get the values.Considering this I cant use the 
existing array "d" to find the inserts, deletes and substitutes.Correct me if I 
am wrong in the above.
Do you want me to use a new 1d array (which contains the entire data from the 
matrix) instead of 2d array (1d vs 2d, improve in performance?)?
Kindly comment.
Do let me know if i am not clear in the above.
Thank you,
Regards,Don Jeba.

  From: don jeba 
 To: Commons Developers List ; Bruno P. Kinoshita 
 
 Sent: Tuesday, 25 October 2016 9:15 PM
 Subject: Re: [TEXT] TEXT-10 A more complex Levenshtein distance
   
Hi Bruno,          Now the comment on formatting is fixed. I will be careful on 
this the next time.
My understanding is, we need to traverse from the diagonal element [right 
bottom corner] to find whether whether its insert or delete or substitute. I 
might be wrong.
Regarding using 1D array instead of 2D array, I think it should be possible. I 
will also give a try.
Thank you,
Regards,Don Jeba.

  From: Bruno P. Kinoshita 
 To: Commons Developers List ; don jeba 
 
 Sent: Monday, 24 October 2016 8:15 AM
 Subject: Re: [TEXT] TEXT-10 A more complex Levenshtein distance
  
Hi Don,

Could you take a look at the tabs/spaces in the pull request, please?

In the meantime, I'll play with the code to see if

i) we can use the two-array algorithm instead; where we analyse two lines each 
time, instead of keeping the whole matrix. Will probably have to compute the 
LevenshteinResults on-the-fly for that, instead of in a separate method.

ii) check if it would be doable to use the one array + temporary variables algo 
instead, and also compute the insert+delete+substitute on the fly.

Just need a couple of hours to play with the code and run your tests to make 
sure it is working :)

Cheers
Bruno



>
> From: don jeba 
>To: Commons Developers List ; Bruno P. Kinoshita 
> 
>Sent: Monday, 17 October 2016 11:44 PM
>Subject: Re: [TEXT] TEXT-10 A more complex Levenshtein distance
> 
>
>Hi Bruno,
>Thank you for the review.
>The one in lang gets only the distance (insert+delete+substitute). To get the 
>individual values, (my understanding is), I need to iterate the diagonal 
>elements in matrix, also need to know the elements at the left and top of the 
>diagonal element to find whether its an insertion or deletion or substitution. 
>Considering this I have used 2 dimensional array.
>Regards,
>Don Jeba.
>
>      From: Bruno P. Kinoshita 
>
>To: Commons Developers List ; don jeba 
> 
>Sent: Monday, 17 October 2016 7:37 AM
>Subject: Re: [TEXT] TEXT-10 A more complex Levenshtein distance
>  
>Hi Don Jeba,
>
>I will have a look at your implementation to compare with a recent improvement 
>in [lang] 
>https://github.com/apache/commons-lang/blob/78134f6b3f1facd019e604d2cd000c4ce7cf9a0a/src/main/java/org/apache/commons/lang3/StringUtils.java#L7710
>
>Instead of keeping a matrix (or even only two rows) the current version in 
>StringUtils keeps just one array and a couple of helper temporary variables.
>
>Not sure if we can re-use it, adding the new features in TEXT-10 (i.e. 
>insert/delete/substitution counts), but if possible that'd be better.
>
>Cheers
>Bruno
>
>
>
>
>- Original Message -
>> From: don jeba 
>> To: Commons Developers List 
>> Sent: Monday, 17 October 2016 1:51 AM
>> Subject: [TEXT] TEXT-10 A more complex Levenshtein distance
>> 
>> Hello,        I am new to open source contribution.
>> Lately I gave a pull request to common-text. I dont know whether I am 
>> missing 
>> any procedure to contribute to common-text. Kindly correct me so that I can 
>> do 
>> the necessary so that someone will review and comment on my code.
>> Jira TEXT-10
>> 
>> https://github.com/apache/commons-text/pull/6
>> 
>> Kindly advise.
>> Thank you,
>> Regards,Don Jeba.
>> 
>
>-
>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: [crypto] package access on ivars?

[Sun, Dapeng]

Hi Gary,

>> I see ivars left at the package access level. This must be an oversight, 
>> right?
Thank you for the suggestion, I will fix it.

>> We can only fix that in 2.0 and a new package. What a bummer!
I'm agreed with you, the new package could also contain the recent fixes. Thank 
you :)

Regards,
Dapeng

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Monday, November 7, 2016 3:56 AM
To: Commons Developers List 
Subject: [crypto] package access on ivars?

Hi all,

I see ivars left at the package access level. This must be an oversight, right?

We can only fix that in 2.0 and a new package. What a bummer!

Gary

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

Re: [Text,Lang] Moving code into commons-text

[Gary Gregory]

On Sun, Nov 6, 2016 at 12:22 PM, Bruno P. Kinoshita <
brunodepau...@yahoo.com.br.invalid> wrote:

> Hi Rob,
>
> > I’ve heard of some intent to get the text functionality out of Lang in
> the long
> > term future and am thinking about starting to chip away at doing this.
> It seems
> > that minimally moving over “org.apache.commons.lang3.text" would be a
> > start. Does anyone have any thoughts about what else might migrate from
> Lang
> > into Text?
>
> I haven't looked at all of the code under o.a.c.l.text, but it sounds like
> a good plan. We can start with a import of the package, and then refine and
> check if everything fits into [text], and if there are no other
> classes/methods in [lang] that depend on this package.
>
>
> There are methods in StringUtils that could be implemented in [text] too.
> For example, the Levenshtein edit distance, and the Jaro Wrinkler
> similarity metric have been ported over as separate objects (which needs
> better modeling actually, see https://issues.apache.org/
> jira/browse/TEXT-21)
>
> I think moving o.a.c.l.text and pruning StringUtils a little bit would be
> a great start for an initial release of [text], and simplify [lang] a
> little bit too.
>

+1 to all of that :-)

Gary


>
>
> Cheers
> Bruno
>
>
>
> - Original Message -
> > From: Rob Tompkins 
> > To: Commons Developers List 
> > Sent: Monday, 7 November 2016 5:20 AM
> > Subject: [Text,Lang] Moving code into commons-text
> >
> > Hi,
> >
> > I’ve heard of some intent to get the text functionality out of Lang in
> the long
> > term future and am thinking about starting to chip away at doing this.
> It seems
> > that minimally moving over “org.apache.commons.lang3.text" would be a
> > start. Does anyone have any thoughts about what else might migrate from
> Lang
> > into Text?
> >
> > 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
>
>


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

Re: [Text,Lang] Moving code into commons-text

[Bruno P. Kinoshita]

Hi Rob,

> I’ve heard of some intent to get the text functionality out of Lang in the 
> long
> term future and am thinking about starting to chip away at doing this. It 
> seems
> that minimally moving over “org.apache.commons.lang3.text" would be a
> start. Does anyone have any thoughts about what else might migrate from Lang
> into Text?

I haven't looked at all of the code under o.a.c.l.text, but it sounds like a 
good plan. We can start with a import of the package, and then refine and check 
if everything fits into [text], and if there are no other classes/methods in 
[lang] that depend on this package.


There are methods in StringUtils that could be implemented in [text] too. For 
example, the Levenshtein edit distance, and the Jaro Wrinkler similarity metric 
have been ported over as separate objects (which needs better modeling 
actually, see https://issues.apache.org/jira/browse/TEXT-21)

I think moving o.a.c.l.text and pruning StringUtils a little bit would be a 
great start for an initial release of [text], and simplify [lang] a little bit 
too.


Cheers
Bruno



- Original Message -
> From: Rob Tompkins 
> To: Commons Developers List 
> Sent: Monday, 7 November 2016 5:20 AM
> Subject: [Text,Lang] Moving code into commons-text
> 
> Hi,
> 
> I’ve heard of some intent to get the text functionality out of Lang in the 
> long 
> term future and am thinking about starting to chip away at doing this. It 
> seems 
> that minimally moving over “org.apache.commons.lang3.text" would be a 
> start. Does anyone have any thoughts about what else might migrate from Lang 
> into Text?
> 
> 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

[crypto] package access on ivars?

[Gary Gregory]

Hi all,

I see ivars left at the package access level. This must be an oversight,
right?

We can only fix that in 2.0 and a new package. What a bummer!

Gary

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

Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers

[Gary Gregory]

The whole post is interesting. Sounds like a fork is inevitable. So much
work though...

Gary

On Nov 6, 2016 9:32 AM, "Stian Soiland-Reyes"  wrote:

> See
> https://mailman.cs.umd.edu/pipermail/findbugs-discuss/
> 2016-November/004321.html
>
> In particular the author is not happy about the BCEL integration:
>
> > The other major reasons for the FindBugs current bad state:
> >
> > 1) The code is very complex, has "organically grown" over a decade, is
> > not documented and has poor public interfaces. Most of the code consists
> > of the very low level bytecode related stuff, tightly coupled with the
> > ancient BCEL library, which doesn't scale and is not multi-thread safe.
> > No one enjoys maintaining this code, at least not me. I see no future
> > for FindBugs with the BCEL approach, and see no way to get rid of it
> > without investing lot of effort, and without breaking every detector and
> > possibly many 3rd party tools. This is the biggest issue we have with
> > FindBugs today, and most likely the root cause for all the evil. This
> > code can't be fixed, it must be rewritten.
>
> ..but the main problem seems to be lack of maintaners.
>
>
> --
> Stian Soiland-Reyes
> http://orcid.org/-0001-9842-9718
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers

[Dave Brosius]

The problem is the admin/owner has left and refuses to give access to 
anyone else. The team has already decided to hard - fork, and is working 
to get set up. Anyone interested in joining is welcome.


Contact me if interested.


On 11/06/2016 12:32 PM, Stian Soiland-Reyes wrote:

See
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html

In particular the author is not happy about the BCEL integration:


The other major reasons for the FindBugs current bad state:

1) The code is very complex, has "organically grown" over a decade, is
not documented and has poor public interfaces. Most of the code consists
of the very low level bytecode related stuff, tightly coupled with the
ancient BCEL library, which doesn't scale and is not multi-thread safe.
No one enjoys maintaining this code, at least not me. I see no future
for FindBugs with the BCEL approach, and see no way to get rid of it
without investing lot of effort, and without breaking every detector and
possibly many 3rd party tools. This is the biggest issue we have with
FindBugs today, and most likely the root cause for all the evil. This
code can't be fixed, it must be rewritten.

..but the main problem seems to be lack of maintaners.





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

FindBugs project announced as 'dead', blaims code rot and lack of maintainers

[Stian Soiland-Reyes]

See
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html

In particular the author is not happy about the BCEL integration:

> The other major reasons for the FindBugs current bad state:
>
> 1) The code is very complex, has "organically grown" over a decade, is
> not documented and has poor public interfaces. Most of the code consists
> of the very low level bytecode related stuff, tightly coupled with the
> ancient BCEL library, which doesn't scale and is not multi-thread safe.
> No one enjoys maintaining this code, at least not me. I see no future
> for FindBugs with the BCEL approach, and see no way to get rid of it
> without investing lot of effort, and without breaking every detector and
> possibly many 3rd party tools. This is the biggest issue we have with
> FindBugs today, and most likely the root cause for all the evil. This
> code can't be fixed, it must be rewritten.

..but the main problem seems to be lack of maintaners.


-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

[Text,Lang] Moving code into commons-text

[Rob Tompkins]

Hi,

I’ve heard of some intent to get the text functionality out of Lang in the long 
term future and am thinking about starting to chip away at doing this. It seems 
that minimally moving over “org.apache.commons.lang3.text" would be a start. 
Does anyone have any thoughts about what else might migrate from Lang into Text?

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

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC2

[Oliver Heger]

Hi,

sorry, I don't want to stand in the way of the release. It is just that
in the past we used to be very careful with artifacts deployed to Maven
central and their compatibility. When I did alpha and beta releases for
[configuration] 2.0 it was decided that these artifacts must not be
published to Maven central because incompatibilities between succeeding
alphas/betas or the final 2.0 version are likely.

If the JCS betas are going to Maven central, I therefore assumed that
some means were taken to deal with incompatibilities. Otherwise, if some
3rd party project has the (stupid) idea to depend on such a beta, we are
in jar hell.

Oliver

Am 05.11.2016 um 23:52 schrieb Gary Gregory:
> There is no need to maintain BC since 2.0 is not out. Changing package
> names and Maven coordinates must also happen hand in hand. Changing one
> means changing the other.
> 
> Gary
> 
> On Nov 5, 2016 1:37 PM, "Thomas Vandahl"  wrote:
> 
>> Hi Oliver,
>>
>> On 05.11.16 21:18, Oliver Heger wrote:
>>> It seems that there are many breaking changes between this release and
>>> beta1; for instance, the clirr report for the core component lists
>>> numerous errors. Is it not against Commons policy to publish
>>> incompatible artifacts with the same maven and package coordinates to
>>> Maven central?
>>
>> I thought that is why we call it "beta"? It basically boils down again
>> to the question what should be considered a public API (which btw hasn't
>> changed since beta-1).
>> I have no problem with changing the coordinates but I'm pretty sure that
>> the next iteration to 2.0 final will introduce more incompatibilities
>> and we may run out of coordinates...
>>
>> As I see it, we are still in the transition from 1.3
>> (org.apache.jcs:jcs) to 2.0 (org.apache.commons.jcs:commons-jcs-core)
>> but I'm ready to change whatever is necessary to get this out of the door.
>>
>> Bye, Thomas.
>>
>>
>> -
>> 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: [DAEMON] Outdated parent pom

[Mark Thomas]

On 06/11/2016 09:07, Guillaume Ch wrote:
> Hello,
> 
> I've noticed that daemon parent pom version is 35, why not upgrading to 41
> now ?

Just haven't got around to it. I've just tested it and there are no
immediately obvious issues so I'll commit it shortly.

Mark


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

Re: commons-io git repository write access

[Pascal Schumacher]

Are you sure this works for commons-io?

I tried a configuration similar to commons-lang, but get:

"remote: You are not authorized to edit this repository."

Am 05.11.2016 um 23:54 schrieb Gary Gregory:

Nothing if you are an Apache committer already, you have karma
automatically.

Gary

On Nov 5, 2016 2:43 PM, "Pascal Schumacher" 
wrote:


Hello everybody,

if nobody objects I would like to help maintaining commons-io.

What would I have to do in order to get write access to the git repository?

-Pascal


-
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

[DAEMON] Outdated parent pom

[Guillaume Ch]

Hello,

I've noticed that daemon parent pom version is 35, why not upgrading to 41
now ?