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

[Bruno P. Kinoshita]

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:

https://github.com/tdebatty/java-string-similarity

And also Talend (I think Data Quality has some string distances). However, I 
think having the API design, and some string distances implemented could be 
enough for a 1.0. Then we can add more, and release more
versions.


Cheers
Bruno



- Original Message -
> From: Rob Tompkins 
> To: Commons Developers List 
> Sent: Monday, 19 December 2016 3:47 PM
> Subject: [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 distance based upon the 
> longest 
> common substring. It feels a tad coarse, but that doesn’t necessarily mean 
> that 
> it’s not worth including.
> 
> Other thoughts and ideas?
> 
> 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

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

[Rob Tompkins]

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 distance based upon the longest 
common substring. It feels a tad coarse, but that doesn’t necessarily mean that 
it’s not worth including.

Other thoughts and ideas?

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

[Rob Tompkins]

> 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 later whether we include it or not, I'd be fine with that.
> Though I'd be happy with a 1.0 release with shaded methods too. So I
> believe my vote would be a +0 :)
> 

I'm a +0 here as well. Feels like fewer dependencies is a better practice, but 
I'm ok with including now or down the road. 

-Rob

> Hope that helps
> Bruno
> 
> 
> 
> 
> - Original Message -
>> From: Pascal Schumacher 
>> To: Commons Developers List 
>> Sent: Monday, 19 December 2016 7:06 AM
>> Subject: [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 dependency 
>> for two methods (less than 60 lines of code) is a good idea.
>> 
>> What do you think?
>> 
>> -Pascal
>> 
>> P.S.: I have created a pull request: 
>> https://github.com/apache/commons-text/pull/18/files to demonstrate the 
>> changes necessary for the removal.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -
>> 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] Remove Commons Lang Dependency?

[Bruno P. Kinoshita]

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 with a 1.0 release with shaded methods too. So I
believe my vote would be a +0 :)

Hope that helps
Bruno




- Original Message -
> From: Pascal Schumacher 
> To: Commons Developers List 
> Sent: Monday, 19 December 2016 7:06 AM
> Subject: [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 dependency 
> for two methods (less than 60 lines of code) is a good idea.
> 
> What do you think?
> 
> -Pascal
> 
> P.S.: I have created a pull request: 
> https://github.com/apache/commons-text/pull/18/files to demonstrate the 
> changes necessary for the removal.
> 
> 
> 
> 
> 
> 
> 
> -
> 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] Support for generating random strings?

[Bruno P. Kinoshita]

+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 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 flavour of what I’m proposing, please see the linked mail threads 
>and also the gist at 
>https://gist.github.com/dmjones500/da2f61a0234f428748417bf1443c0dff. Some of 
>the predicate stuff I’ve proposed may have wider uses within TEXT and could 
>warrant breaking out into its own class.
>
>Thanks,
>Duncan
>
>
>
>[1] http://markmail.org/message/buhfuzb2tsc6k2z6
>-
>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] Remove Commons Lang Dependency?

[sebb]

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#containsAny
>>
>> StringUtils#containsNone
>>
>> As dependencies should be minimized I'm not sure if adding a dependency
>> for two methods (less than 60 lines of code) is a good idea.
>>
>> What do you think?
>
> Actually I don't understand why do you want to remove it. It was made
> dependent on purpose. The shade plugin - if properly configured - will only
> include StringUtils as a private package in commons-text - so this
> dependency exists only at build time. We had a bad history of copied code in
> commons, because the original code got bug fixes and the copies were never
> updated later on.

In which case what needs to be done is to document this decision -
e.g. in the pom - so future maintainers don't have to go through this
again.

> Cheers,
> Jörg
>
>
> -
> 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] Remove Commons Lang Dependency?

[Jörg Schaible]

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 should be minimized I'm not sure if adding a dependency
> for two methods (less than 60 lines of code) is a good idea.
> 
> What do you think?

Actually I don't understand why do you want to remove it. It was made 
dependent on purpose. The shade plugin - if properly configured - will only 
include StringUtils as a private package in commons-text - so this 
dependency exists only at build time. We had a bad history of copied code in 
commons, because the original code got bug fixes and the copies were never 
updated later on.

Cheers,
Jörg


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

[sebb]

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 later decided the TEXT should support more of such methods
they can be made external at that point.

On 18 December 2016 at 18:10, Matt Sicker  wrote:
> 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 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 dependency
>> for two methods (less than 60 lines of code) is a good idea.
>>
>> What do you think?
>>
>> -Pascal
>>
>> P.S.: I have created a pull request: https://github.com/apache/comm
>> ons-text/pull/18/files to demonstrate the changes necessary for the
>> removal.
>>
>>
>>
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> Matt Sicker 

-
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

[Apache Jenkins Server]

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 » Apache Commons JCS :: Core #193

[Apache Jenkins Server]

See 



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

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

[Apache Jenkins Server]

See 


Changes:

[tv] Not used

[tv] Initialization should not be a publicly accessible method

--
[INFO] 
[INFO] 
[INFO] Building Apache Commons JCS :: Core 2.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @ commons-jcs-core ---
[INFO] Deleting 

[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-3) @ 
commons-jcs-core ---
[INFO] 
[INFO] --- build-helper-maven-plugin:1.10:parse-version (parse-version) @ 
commons-jcs-core ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.8:run (javadoc.resources) @ commons-jcs-core 
---
[INFO] Skipping Antrun execution
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ 
commons-jcs-core ---
[INFO] 
[INFO] --- buildnumber-maven-plugin:1.4:create (default) @ commons-jcs-core ---
[INFO] Executing: /bin/sh -c cd 
'
 && 'svn' '--non-interactive' 'info'
[INFO] Working directory: 

[INFO] Storing buildNumber: 1774921 at timestamp: 1482082836541
[INFO] Executing: /bin/sh -c cd 
'
 && 'svn' '--non-interactive' 'info'
[INFO] Working directory: 

[INFO] Storing buildScmBranch: trunk
[INFO] 
[INFO] --- maven-resources-plugin:2.7:resources (default-resources) @ 
commons-jcs-core ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 0 resource to 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @ 
commons-jcs-core ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 234 source files to 

[INFO] 
:
 Some input files use unchecked or unsafe operations.
[INFO] 
:
 Recompile with -Xlint:unchecked for details.
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
:[83,5]
 method does not override or implement a method from a supertype
[ERROR] 
:[100,5]
 method does not override or implement a method from a supertype
[INFO] 2 errors 
[INFO] -

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

Build failed in Jenkins: commons-jcs #192

[Apache Jenkins Server]

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 (ubuntu) in workspace 

Updating https://svn.apache.org/repos/asf/commons/proper/jcs/trunk at revision 
'2016-12-18T18:10:19.650 +'
U 
commons-jcs-jcache/src/test/java/org/apache/commons/jcs/jcache/CacheTest.java
U 
commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java
U commons-jcs-tck-tests/pom.xml
U 
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/behavior/ICacheEventQueue.java
D 
commons-jcs-core/src/test/java/org/apache/commons/jcs/engine/MockCacheEventQueue.java
At revision 1774921

WARNING: clock of the subversion server appears to be out of sync. This can 
result in inconsistent check out behavior.
Parsing POMs
Modules changed, recalculating dependency graph
Established TCP socket on 32918
maven3-agent.jar already up to date
maven3-interceptor.jar already up to date
maven3-interceptor-commons.jar already up to date
[commons-jcs] $ /home/jenkins/tools/java/latest1.7/bin/java -Xmx2g -Xms256m 
-XX:MaxPermSize=512m -cp 
/home/jenkins/jenkins-slave/maven3-agent.jar:/home/jenkins/tools/maven/apache-maven-3.0.5/boot/plexus-classworlds-2.4.jar
 org.jvnet.hudson.maven3.agent.Maven3Main 
/home/jenkins/tools/maven/apache-maven-3.0.5 
/home/jenkins/jenkins-slave/slave.jar 
/home/jenkins/jenkins-slave/maven3-interceptor.jar 
/home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 32918
<===[JENKINS REMOTING CAPACITY]===>   channel started
Executing Maven:  -B -f  
-Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/1 clean 
install -B -U -e -fae -V -DskipBenchmarks=true -DfailIfNoTests=false 
-Dtest=BasicRemoteCacheClientServerUnitTest
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 
13:51:28+)
Maven home: /usr/local/asfpackages/maven/apache-maven-3.0.5
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: /usr/local/asfpackages/java/jdk1.7.0_80/jre
Default locale: en_US, platform encoding: ISO-8859-1
OS name: "linux", version: "4.4.0-47-generic", arch: "amd64", family: "unix"
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] Apache Commons JCS
[INFO] Apache Commons JCS :: Core
[INFO] Apache Commons JCS :: JCache
[INFO] Apache Commons JCS :: JCache TCK
[INFO] Apache Commons JCS :: JCache Extras
[INFO] Apache Commons JCS :: JCache OpenJPA
[INFO] Apache Commons JCS :: Distribution
[INFO] 
[INFO] 
[INFO] Building Apache Commons JCS 2.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @ commons-jcs ---
[INFO] Deleting 
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-3) @ commons-jcs 
---
[INFO] 
[INFO] --- build-helper-maven-plugin:1.10:parse-version (parse-version) @ 
commons-jcs ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.8:run (javadoc.resources) @ commons-jcs ---
[INFO] Skipping Antrun execution
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ commons-jcs ---
[INFO] 
[INFO] --- buildnumber-maven-plugin:1.4:create (default) @ commons-jcs ---
[INFO] Executing: /bin/sh -c cd 
' && 'svn' '--non-interactive' 
'info'
[INFO] Working directory: 
[INFO] Storing buildNumber: 1774921 at timestamp: 1482082833279
[INFO] Executing: /bin/sh -c cd 
' && 'svn' '--non-interactive' 
'info'
[INFO] Working directory: 
[INFO] Storing buildScmBranch: trunk
[INFO] 
[INFO] --- maven-bundle-plugin:3.0.1:manifest (bundle-manifest) @ commons-jcs 
---
[WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle]
[INFO] 
[INFO] --- animal-sniffer-maven-plugin:1.15:check (checkAPIcompatibility) @ 
commons-jcs ---
[INFO] Checking unresolved references to org.codehaus.mojo.signature:java16:1.0
[INFO] 
[INFO] --- maven-site-plugin:3.4:attach-descriptor (attach-descriptor) @ 
commons-jcs ---
[INFO] 
[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ commons-jcs 
---
[INFO] Installing  to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/commons/commons-jcs/2.0-SN

Re: [TEXT] Remove Commons Lang Dependency?

[Matt Sicker]

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 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 dependency
> for two methods (less than 60 lines of code) is a good idea.
>
> What do you think?
>
> -Pascal
>
> P.S.: I have created a pull request: https://github.com/apache/comm
> ons-text/pull/18/files to demonstrate the changes necessary for the
> removal.
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Matt Sicker 

[TEXT] Remove Commons Lang Dependency?

[Pascal Schumacher]

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 dependency 
for two methods (less than 60 lines of code) is a good idea.


What do you think?

-Pascal

P.S.: I have created a pull request: 
https://github.com/apache/commons-text/pull/18/files to demonstrate the 
changes necessary for the removal.








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

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

[Pascal Schumacher]

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 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: fix
javadoc warnings
To: 
Cc:

Repository: commons-io

Updated Branches:
   refs/heads/master 593de775b -> 4aebb1129


MessageDigestCalculatingInputStream: fix javadoc warnings


Project: http://git-wip-us.apache.org/repos/asf/commons-io/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-io/commit/4aebb112
Tree: http://git-wip-us.apache.org/repos/asf/commons-io/tree/4aebb112
Diff: http://git-wip-us.apache.org/repos/asf/commons-io/diff/4aebb112

Branch: refs/heads/master
Commit: 4aebb1129d397b20c8f911ccdf1e3595f020d127
Parents: 593de77
Author: pascalschumacher 
Authored: Sun Dec 18 14:34:23 2016 +0100
Committer: pascalschumacher 
Committed: Sun Dec 18 14:34:39 2016 +0100

--
  .../io/input/MessageDigestCalculatingInputStream.java| 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/commons-io/blob/
4aebb112/src/main/java/org/apache/commons/io/input/
MessageDigestCalculatingInputStream.java
--
diff --git a/src/main/java/org/apache/commons/io/input/
MessageDigestCalculatingInputStream.java b/src/main/java/org/apache/
commons/io/input/MessageDigestCalculatingInputStream.java
index cfb345d..c360560 100644
--- a/src/main/java/org/apache/commons/io/input/
MessageDigestCalculatingInputStream.java
+++ b/src/main/java/org/apache/commons/io/input/
MessageDigestCalculatingInputStream.java
@@ -24,12 +24,13 @@ import java.security.NoSuchAlgorithmException;

  /**
   * This class is an example for using an {@link ObservableInputStream}. It
- * creates its own {@link Observer}, which calculates a checksum using a
- * MessageDigest, for example an MD5 sum.
- * {@em Note}: Neither {@link ObservableInputStream}, nor {@link
MessageDigest},
+ * creates its own {@link org.apache.commons.io.input.
ObservableInputStream.Observer},
+ * which calculates a checksum using a MessageDigest, for example an MD5
sum.
+ * Note: Neither {@link ObservableInputStream}, nor {@link
MessageDigest},
   * are thread safe. So is {@link MessageDigestCalculatingInputStream}.
   */
  public class MessageDigestCalculatingInputStream extends
ObservableInputStream {
+
  public static class MessageDigestMaintainingObserver extends
Observer {
  private final MessageDigest md;

@@ -58,12 +59,14 @@ public class MessageDigestCalculatingInputStream
extends ObservableInputStream {
  messageDigest = pDigest;
  add(new MessageDigestMaintainingObserver(pDigest));
  }
+
  /** Creates a new instance, which calculates a signature on the given
stream,
   * using a {@link MessageDigest} with the given algorithm.
   */
  public MessageDigestCalculatingInputStream(InputStream pStream,
String pAlgorithm) throws NoSuchAlgorithmException {
  this(pStream, MessageDigest.getInstance(pAlgorithm));
  }
+
  /** Creates a new instance, which calculates a signature on the given
stream,
   * using a {@link MessageDigest} with the "MD5" algorithm.
   */
@@ -73,7 +76,7 @@ public class MessageDigestCalculatingInputStream
extends ObservableInputStream {

  /** Returns the {@link MessageDigest}, which is being used for
generating the
   * checksum.
- * {@em Note}: The checksum will only reflect the data, which has
been read so far.
+ * Note: The checksum will only reflect the data, which has
been read so far.
   * This is probably not, what you expect. Make sure, that the
complete data has been
   * read, if that is what you want. The easiest way to do so is by
invoking
   * {@link #consume()}.





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

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

[Gary Gregory]

+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, 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 since 1.0, and this is just an improved version of
> existing
>  functionality.
> >>> I don't think RandomStringUtils itself belongs in LANG, now that there
> >>> is a TEXT component.
> >>>
> >>> Quite a few TEXT-like classes were added to LANG because there was
> nowhere else.
> >> I agree with this. Creating random strings is not really a missing
> feature from java.lang.*.
> >>
> >> We should add a similar class to TEXT, but take the opportunity to
> simplify some of the complicated semantics of the current version. We can
> then deprecated RandomStringUtils and remove it in 4.0.
> >
> > What about adding only your new methods (removing the Unicode suffix) as
> RandomStringUtils to text?
> >
>
> Based on our last conversation about TEXT, the line between LANG and TEXT
> seems to be if an arbitrary application developer would find the utility
> useful on a day to day basis, then LANG is the spot for it. Otherwise, the
> developer is writing something that actually processes and manipulates
> text, which seems to be the use case for TEXT.
>
> So this feels more "texty" than "langy" to me, but I could go either way.
>
> Also, my goal is to get TEXT ready to go out in the next month or so
> (granted I've not done a release before, so I might need guidance there).
>
> 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
>
>

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

[Gary Gregory]

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: fix
javadoc warnings
To: 
Cc:

Repository: commons-io
> Updated Branches:
>   refs/heads/master 593de775b -> 4aebb1129
>
>
> MessageDigestCalculatingInputStream: fix javadoc warnings
>
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-io/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-io/commit/4aebb112
> Tree: http://git-wip-us.apache.org/repos/asf/commons-io/tree/4aebb112
> Diff: http://git-wip-us.apache.org/repos/asf/commons-io/diff/4aebb112
>
> Branch: refs/heads/master
> Commit: 4aebb1129d397b20c8f911ccdf1e3595f020d127
> Parents: 593de77
> Author: pascalschumacher 
> Authored: Sun Dec 18 14:34:23 2016 +0100
> Committer: pascalschumacher 
> Committed: Sun Dec 18 14:34:39 2016 +0100
>
> --
>  .../io/input/MessageDigestCalculatingInputStream.java| 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/commons-io/blob/
> 4aebb112/src/main/java/org/apache/commons/io/input/
> MessageDigestCalculatingInputStream.java
> --
> diff --git a/src/main/java/org/apache/commons/io/input/
> MessageDigestCalculatingInputStream.java b/src/main/java/org/apache/
> commons/io/input/MessageDigestCalculatingInputStream.java
> index cfb345d..c360560 100644
> --- a/src/main/java/org/apache/commons/io/input/
> MessageDigestCalculatingInputStream.java
> +++ b/src/main/java/org/apache/commons/io/input/
> MessageDigestCalculatingInputStream.java
> @@ -24,12 +24,13 @@ import java.security.NoSuchAlgorithmException;
>
>  /**
>   * This class is an example for using an {@link ObservableInputStream}. It
> - * creates its own {@link Observer}, which calculates a checksum using a
> - * MessageDigest, for example an MD5 sum.
> - * {@em Note}: Neither {@link ObservableInputStream}, nor {@link
> MessageDigest},
> + * creates its own {@link org.apache.commons.io.input.
> ObservableInputStream.Observer},
> + * which calculates a checksum using a MessageDigest, for example an MD5
> sum.
> + * Note: Neither {@link ObservableInputStream}, nor {@link
> MessageDigest},
>   * are thread safe. So is {@link MessageDigestCalculatingInputStream}.
>   */
>  public class MessageDigestCalculatingInputStream extends
> ObservableInputStream {
> +
>  public static class MessageDigestMaintainingObserver extends
> Observer {
>  private final MessageDigest md;
>
> @@ -58,12 +59,14 @@ public class MessageDigestCalculatingInputStream
> extends ObservableInputStream {
>  messageDigest = pDigest;
>  add(new MessageDigestMaintainingObserver(pDigest));
>  }
> +
>  /** Creates a new instance, which calculates a signature on the given
> stream,
>   * using a {@link MessageDigest} with the given algorithm.
>   */
>  public MessageDigestCalculatingInputStream(InputStream pStream,
> String pAlgorithm) throws NoSuchAlgorithmException {
>  this(pStream, MessageDigest.getInstance(pAlgorithm));
>  }
> +
>  /** Creates a new instance, which calculates a signature on the given
> stream,
>   * using a {@link MessageDigest} with the "MD5" algorithm.
>   */
> @@ -73,7 +76,7 @@ public class MessageDigestCalculatingInputStream
> extends ObservableInputStream {
>
>  /** Returns the {@link MessageDigest}, which is being used for
> generating the
>   * checksum.
> - * {@em Note}: The checksum will only reflect the data, which has
> been read so far.
> + * Note: The checksum will only reflect the data, which has
> been read so far.
>   * This is probably not, what you expect. Make sure, that the
> complete data has been
>   * read, if that is what you want. The easiest way to do so is by
> invoking
>   * {@link #consume()}.
>
>

Re: [LANG] LANG-1301

[Pascal Schumacher]

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.

Kind regards,
Pascal

Am 18.12.2016 um 16:19 schrieb Karl Heinz Marbaise:

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

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

[Karl Heinz Marbaise]

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

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 additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] LANG-1301

[Karl Heinz Marbaise]

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 regards
Karl Heinz Marbaise


Kind regards,
Pascal

Am 18.12.2016 um 16:06 schrieb Karl Heinz Marbaise:

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 additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] LANG-1301

[Pascal Schumacher]

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:

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

[LANG] LANG-1301

[Karl Heinz Marbaise]

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 additional commands, e-mail: dev-h...@commons.apache.org

Re: [TEXT] Support for generating random strings?

[Rob Tompkins]

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 creating a similar class within TEXT? I’d be 
> happy to work on this and produce a first draft class.
> 
> To give a flavour of what I’m proposing, please see the linked mail threads 
> and also the gist at 
> https://gist.github.com/dmjones500/da2f61a0234f428748417bf1443c0dff. Some of 
> the predicate stuff I’ve proposed may have wider uses within TEXT and could 
> warrant breaking out into its own class.
> 
> Thanks,
> Duncan
> 
> 
> 
> [1] http://markmail.org/message/buhfuzb2tsc6k2z6
> -
> 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

[TEXT] Support for generating random strings?

[Duncan Jones]

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 flavour of what I’m proposing, please see the linked mail threads and 
also the gist at 
https://gist.github.com/dmjones500/da2f61a0234f428748417bf1443c0dff. Some of 
the predicate stuff I’ve proposed may have wider uses within TEXT and could 
warrant breaking out into its own class.
 
Thanks,
Duncan



[1] http://markmail.org/message/buhfuzb2tsc6k2z6
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

[Rob Tompkins]

> 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 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.
>>> I don't think RandomStringUtils itself belongs in LANG, now that there
>>> is a TEXT component.
>>> 
>>> Quite a few TEXT-like classes were added to LANG because there was nowhere 
>>> else.
>> I agree with this. Creating random strings is not really a missing feature 
>> from java.lang.*.
>> 
>> We should add a similar class to TEXT, but take the opportunity to simplify 
>> some of the complicated semantics of the current version. We can then 
>> deprecated RandomStringUtils and remove it in 4.0.
> 
> What about adding only your new methods (removing the Unicode suffix) as 
> RandomStringUtils to text?
> 

Based on our last conversation about TEXT, the line between LANG and TEXT seems 
to be if an arbitrary application developer would find the utility useful on a 
day to day basis, then LANG is the spot for it. Otherwise, the developer is 
writing something that actually processes and manipulates text, which seems to 
be the use case for TEXT. 

So this feels more "texty" than "langy" to me, but I could go either way. 

Also, my goal is to get TEXT ready to go out in the next month or so (granted 
I've not done a release before, so I might need guidance there). 

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: [LANG] [RNG] New Unicode-capable additions to RandomStringUtils

[Pascal Schumacher]

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 been
part of LANG since 1.0, and this is just an improved version of existing
functionality.

I don't think RandomStringUtils itself belongs in LANG, now that there
is a TEXT component.

Quite a few TEXT-like classes were added to LANG because there was nowhere else.

I agree with this. Creating random strings is not really a missing feature from 
java.lang.*.

We should add a similar class to TEXT, but take the opportunity to simplify 
some of the complicated semantics of the current version. We can then 
deprecated RandomStringUtils and remove it in 4.0.


What about adding only your new methods (removing the Unicode suffix) as 
RandomStringUtils to text?


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

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

[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 been
>> part of LANG since 1.0, and this is just an improved version of existing
>> functionality.
> 
> I don't think RandomStringUtils itself belongs in LANG, now that there
> is a TEXT component.
> 
> Quite a few TEXT-like classes were added to LANG because there was nowhere 
> else.

I agree with this. Creating random strings is not really a missing feature from 
java.lang.*.

We should add a similar class to TEXT, but take the opportunity to simplify 
some of the complicated semantics of the current version. We can then 
deprecated RandomStringUtils and remove it in 4.0.


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


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

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

[sebb]

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

I don't think RandomStringUtils itself belongs in LANG, now that there
is a TEXT component.

Quite a few TEXT-like classes were added to LANG because there was nowhere else.

>
>
> -
> 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] New Unicode-capable additions to RandomStringUtils

[Pascal Schumacher]

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

Signature is:

   public static String randomUnicode(final int count, final int minCodePoint, 
final int maxCodePoint,
 final Set include, final Random random)


Expected overloads:


   public static String randomUnicode(final int count, final int minCodePoint, final 
int maxCodePoint, final Set include)
   public static String randomUnicode(final int count, final int minCodePoint, 
final int maxCodePoint)
   public static String randomUnicode(final int count)

And possibly:

   public static String randomNumberUnicode(final int count)
   public static String randomAlphabeticUnicode(final int count)
   public static String randomAlphanumericUnicode(final int count)

+1 to adding these overloads

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

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

[Pascal Schumacher]

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.



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

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

[Pascal Schumacher]

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.



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

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

[sebb]

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 
> RandomUtils made sense (LANG-1299), since that was about the functionality 
> offered by the generator itself.
>
> If RNG will become a repository of things you could do with a random 
> generator, rather than just implementations of the generators, then I agree 
> with your suggestion. If not, then I could imagine this random string 
> generation staying in Lang or perhaps moving to Text.

I think this belongs in TEXT rather than LANG or RNG

Just because it involves random choices does not mean it belongs in RNG.
It is an application of a random generator.

It's definitely too specialised for LANG.

It should be able to *use* RNG for the generator if required.

> Duncan
>
>>
>> On Dec 17, 2016 10:39 PM, "Duncan Jones"  wrote:
>>
>>> On reflection, a bad choice of subject line. The other methods are
>>> Unicode-capable, but just very rooted in thinking about char data types.
>>>
 On 18 Dec 2016, at 06:38, Duncan Jones  wrote:

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

 Signature is:

 public static String randomUnicode(final int count, final int
>>> minCodePoint, final int maxCodePoint,
   final Set include, final Random random)


 Expected overloads:


 public static String randomUnicode(final int count, final int
>>> minCodePoint, final int maxCodePoint, final Set include)
 public static String randomUnicode(final int count, final int
>>> minCodePoint, final int maxCodePoint)
 public static String randomUnicode(final int count)

 And possibly:

 public static String randomNumberUnicode(final int count)
 public static String randomAlphabeticUnicode(final int count)
 public static String randomAlphanumericUnicode(final int count)


 Any complaints if I add this to the code base? I’ve possibly
>>> overcomplicated the predicate stuff, however it seemed the most flexible
>>> way to specify requirements on the letters. I’ve created two built-in
>>> predicates, but more could be supported (and users can create their own).

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

[compress] SonarQube Build Added

[Stefan Bodewig]

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 figure out why threee
tests fail that don't fail when run on my machine (or Jenkins without
the Sonar and Jacoco setup).

Stefan

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