[compress] SonarQube Build Added

Hi all I've added https://builds.apache.org/view/Apache%20Commons/job/Commons-Compress%20SonarQube/ which results in https://builds.apache.org/analysis/overview?id=12601 Right now it builds whenever the "normal" build has been successfull and I intend to enable email on failed builds once I figur

Re: [LANG] [RNG] New Unicode-capable additions to RandomStringUtils

On 18 December 2016 at 07:04, Duncan Jones wrote: > >> On 18 Dec 2016, at 06:55, Gary Gregory wrote: >> >> I thought we were talking about deprecating any random code in favor of >> Commons RNG? >> >> Gary > > I guess that depends on the scope of RNG. Our previous conversation about > RandomUtil

Re: [LANG] [RNG] New Unicode-capable additions to RandomStringUtils

Am 18.12.2016 um 11:23 schrieb sebb: It's definitely too specialised for LANG. I do not think this is too specialized for LANG. RandomStringUtils has been part of LANG since 1.0, and this is just an improved version of existing functionality. -

Re: [LANG] New Unicode-capable additions to RandomStringUtils

Am 18.12.2016 um 07:55 schrieb Gary Gregory: I thought we were talking about deprecating any random code in favor of Commons RNG? I would not expect functionality like this in a component RNG. If features like this are added to RNG it should be renamed, e.g. to commons-random. --

Re: [LANG] New Unicode-capable additions to RandomStringUtils

Am 18.12.2016 um 07:38 schrieb Duncan Jones: Hi all, I’ve created a variation of RandomStringUtils.random(), which generates the specified number of code points (rather than chars). Implementation can be seen here (https://gist.github.com/dmjones500/da2f61a0234f428748417bf1443c0dff). Signatu

Re: [LANG] [RNG] New Unicode-capable additions to RandomStringUtils

On 18 December 2016 at 10:40, Pascal Schumacher wrote: > Am 18.12.2016 um 11:23 schrieb sebb: >> >> It's definitely too specialised for LANG. > > I do not think this is too specialized for LANG. RandomStringUtils has been > part of LANG since 1.0, and this is just an improved version of existing >

Re: [LANG] [RNG] New Unicode-capable additions to RandomStringUtils

> On 18 Dec 2016, at 10:51, sebb wrote: > > On 18 December 2016 at 10:40, Pascal Schumacher > wrote: >> Am 18.12.2016 um 11:23 schrieb sebb: >>> >>> It's definitely too specialised for LANG. >> >> I do not think this is too specialized for LANG. RandomStringUtils has been >> part of LANG sinc

Re: [LANG] [RNG] New Unicode-capable additions to RandomStringUtils

Am 18.12.2016 um 11:57 schrieb Duncan Jones: On 18 Dec 2016, at 10:51, sebb wrote: On 18 December 2016 at 10:40, Pascal Schumacher wrote: Am 18.12.2016 um 11:23 schrieb sebb: It's definitely too specialised for LANG. I do not think this is too specialized for LANG. RandomStringUtils has b

Re: [LANG] [RNG] New Unicode-capable additions to RandomStringUtils

> On Dec 18, 2016, at 6:10 AM, Pascal Schumacher > wrote: > >> Am 18.12.2016 um 11:57 schrieb Duncan Jones: >> >>> On 18 Dec 2016, at 10:51, sebb wrote: >>> >>> On 18 December 2016 at 10:40, Pascal Schumacher >>> wrote: > Am 18.12.2016 um 11:23 schrieb sebb: > It's definitely too s

[TEXT] Support for generating random strings?

Hi, A recent discussion on LANG/RNG[1] seems to have concluded that RandomStringUtils doesn’t belong in LANG and almost certainly not in RNG either. Would there be any interest in creating a similar class within TEXT? I’d be happy to work on this and produce a first draft class. To give a flav

Re: [TEXT] Support for generating random strings?

Go for it. Open a Jira and have at it. -Rob > On Dec 18, 2016, at 8:13 AM, Duncan Jones wrote: > > Hi, > > A recent discussion on LANG/RNG[1] seems to have concluded that > RandomStringUtils doesn’t belong in LANG and almost certainly not in RNG > either. > > Would there be any interest in

[LANG] LANG-1301

Hi, i would like to apply the attached patch to the code base? any objections to that? Or anything I need to pay attention to? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For a

Re: [LANG] LANG-1301

Hi Karl Heinz, have already applied your patch: https://github.com/apache/commons-lang/commit/6cfee3d0e501f781ac5b25aed0b7278ed6ed9543 Sorry I did not consider the possibility that you would like to do it yourself. :( Kind regards, Pascal Am 18.12.2016 um 16:06 schrieb Karl Heinz Marbaise:

Re: [LANG] LANG-1301

Hi Pascal, On 18/12/16 16:11, Pascal Schumacher wrote: Hi Karl Heinz, have already applied your patch: https://github.com/apache/commons-lang/commit/6cfee3d0e501f781ac5b25aed0b7278ed6ed9543 Sorry I did not consider the possibility that you would like to do it yourself. :( No problem. Kind

Re: [LANG] LANG-1301

Hi Pascal, It looks like you haven't given the references to LANG-1301 in the commit message...;-(...nor you have closed the issue LANG-1301... Kind regards Karl Heinz Marbaise... On 18/12/16 16:11, Pascal Schumacher wrote: Hi Karl Heinz, have already applied your patch: https://github.com/a

Re: [LANG] LANG-1301

Hi Karl Heinz, sorry I would have referenced LANG-1301 in the commit message, but it did not exist (or at least I was not aware of its existence) when I committed. I took you patch from https://issues.apache.org/jira/browse/RAT-225 I have just closed LANG-1301 and added it to changes.xml. K

Fwd: commons-io git commit: MessageDigestCalculatingInputStream: fix javadoc warnings

Wait a sec. Why is this class in IO? We have Commons Codec which contains all things MessageDigest related already. Shouldn't this class be in Codec? Gary -- Forwarded message -- From: Date: Dec 18, 2016 5:34 AM Subject: commons-io git commit: MessageDigestCalculatingInputStream:

Re: [LANG] [RNG] New Unicode-capable additions to RandomStringUtils

+1 to moving this to Text. New code goes in Text. Old code is deprecated and copied. Gary On Dec 18, 2016 5:05 AM, "Rob Tompkins" wrote: > > > > On Dec 18, 2016, at 6:10 AM, Pascal Schumacher > wrote: > > > >> Am 18.12.2016 um 11:57 schrieb Duncan Jones: > >> > >>> On 18 Dec 2016, at 10:51, se

Re: Fwd: commons-io git commit: MessageDigestCalculatingInputStream: fix javadoc warnings

Was added with https://github.com/apache/commons-io/commit/e180578289a5c65e19e430bd3300a72c9ba97a9b which was not released yet. So it could be moved to codec. Am 18.12.2016 um 18:16 schrieb Gary Gregory: Wait a sec. Why is this class in IO? We have Commons Codec which contains all things Messa

[TEXT] Remove Commons Lang Dependency?

Hello everybody, commons-text currently depends on commons-lang. This dependency is included into the jar via the maven shade plugin. Only two methods from lang are really needed: StringUtils#containsAny StringUtils#containsNone As dependencies should be minimized I'm not sure if adding a d

Re: [TEXT] Remove Commons Lang Dependency?

That looks good to me. We do similarly in Log4j. Commons classes tend to be written in such a way that you can copy/paste only what you need if you're trying to prevent required dependencies. On 18 December 2016 at 12:06, Pascal Schumacher wrote: > Hello everybody, > > commons-text currently dep

Build failed in Jenkins: commons-jcs » Apache Commons JCS :: Core #192

See Changes: [tv] Not used [tv] Initialization should not be a publicly accessible method -- [INFO]

Build failed in Jenkins: commons-jcs #192

See Changes: [tv] Not used [tv] Initialization should not be a publicly accessible method -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H16 (ubunt

Jenkins build is back to normal : commons-jcs » Apache Commons JCS :: Core #193

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

Jenkins build is back to normal : commons-jcs #193

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

Re: [TEXT] Remove Commons Lang Dependency?

Looks OK. However it might be confusing to have the same methods in both jars, so at least the class needs to be renamed. Probably best to make the methods internal. Otherwise people might expect other related methods to be supported. This would end up with duplication of LANG methods. If it is l

Re: [TEXT] Remove Commons Lang Dependency?

Pascal Schumacher wrote: > Hello everybody, > > commons-text currently depends on commons-lang. This dependency is > included into the jar via the maven shade plugin. > > Only two methods from lang are really needed: > > StringUtils#containsAny > > StringUtils#containsNone > > As dependencies

Re: [TEXT] Remove Commons Lang Dependency?

On 18 December 2016 at 22:02, Jörg Schaible wrote: > Pascal Schumacher wrote: > >> Hello everybody, >> >> commons-text currently depends on commons-lang. This dependency is >> included into the jar via the maven shade plugin. >> >> Only two methods from lang are really needed: >> >> StringUtils#co

Re: [TEXT] Support for generating random strings?

+1 go for it Duncan. Happy to help testing/reviewing/commenting if necessary. Cheers Bruno > > From: Duncan Jones >To: Commons Developers List >Sent: Monday, 19 December 2016 2:13 AM >Subject: [TEXT] Support for generating random strings? > > >Hi, > >A recent

Re: [TEXT] Remove Commons Lang Dependency?

Hi Pascal, I suspect we may need a few other methods in the future, but for now I agree we are not using much of [lang] in [text]. If you would like to release 1.0 without the [lang] dependency, and then we review it later whether we include it or not, I'd be fine with that. Though I'd be happy w

Re: [TEXT] Remove Commons Lang Dependency?

> On Dec 18, 2016, at 5:08 PM, Bruno P. Kinoshita > wrote: > > Hi Pascal, > > I suspect we may need a few other methods in the future, but for now > I agree we are not using much of [lang] in [text]. > > If you would like to release 1.0 without the [lang] dependency, and then > we review it

[text][TEXT-32] Regarding more edit distances.

Hello, With the thought that we want more "edit distances”/“similarity scores” in the codebase for the potential 1.0 release of TEXT, I’ve opened an associated Jira (TEXT-32). I was wondering if any folks had any input about further ideas. The first idea that I stumbled upon was an edit distanc

Re: [text][TEXT-32] Regarding more edit distances.

Hi Rob, LCS can still be useful for bioinformatics/genetics. So I'd say that's worth including. In Java, if I ever needed it, I would probably look for it at Biojava (which I just did and couldn't easily find it there). As for the other string distances, I always look at this GitHub project: