[VOTE][RESULT] Create new component commons-signing

[Mark Thomas]

The following votes were cast:

Binding:
+1: markt, bodewig, sebb, ebourg, ggregory, oheger, chtompki, ecki

Non-binding:
+1: rmannibucau


Two of the +1 binding votes indicating a preference for Jira rather than
GitHub issues.

The vote therefore passes.

I'll start setting this up soon.

Mark



On 02/02/18 17:54, Mark Thomas wrote:
> Hello all,
> 
> I propose that we create a new component [commons-signing].
> 
> The scope of the component is code signing utilities including, but not
> limited to, Ant and Maven plugins for the Symantec code signing service
> that a number of ASF projects use.
> 
> We'll work most things out as we go along but the rough plan at this
> stage is:
> 
> * git repo
> * start with the Symantec Ant task in Tomcat
> * add the Maven plugin from Sling
> * refactor out the duplicate code
> * first release
> 
> I'm leaning towards using GitHub issues rather than Jira.
> 
> Please review the proposal and vote. This vote will close no sooner that
> 72 hours from now.
> 
>   [ ] +1 Create the component
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this component because…
> 
> Cheers,
> 
> Mark
> 
> -
> 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: [CSV][POLL] How to provide mutable records

[Stian Soiland-Reyes]

On Mon, 12 Feb 2018 18:10:56 -0700, Gary Gregory  wrote:
> On Fri, Feb 9, 2018 at 10:05 AM, Stian Soiland-Reyes 
> I've not had time to review this yet but I hope to get to it sometimes this
> week.

Thanks. I'll wait for that before prepping a 1.6 RC so we get time to
decide if this is in or not.


-- 
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
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: commons-csv git commit: CSV-216: Avoid Arrays.copyOf()

[Gilles]

On Tue, 13 Feb 2018 00:16:13 + (UTC), st...@apache.org wrote:

Repository: commons-csv
Updated Branches:
  refs/heads/CSV-216 637ad2d7a -> f66a83901


CSV-216: Avoid Arrays.copyOf()


Why?


as .clone() will do


We should rather avoid using "clone()".

Gilles


-- at least until someone tries to do
.withValue(x) in an out-of-range column


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


Branch: refs/heads/CSV-216
Commit: f66a83901bd026369a2e8d522bd567eb2ef3f8c0
Parents: 637ad2d
Author: Stian Soiland-Reyes 
Authored: Fri Feb 9 16:49:51 2018 +
Committer: Stian Soiland-Reyes 
Committed: Tue Feb 13 00:14:52 2018 +


--
 src/main/java/org/apache/commons/csv/CSVRecord.java | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--



http://git-wip-us.apache.org/repos/asf/commons-csv/blob/f66a8390/src/main/java/org/apache/commons/csv/CSVRecord.java

--
diff --git a/src/main/java/org/apache/commons/csv/CSVRecord.java
b/src/main/java/org/apache/commons/csv/CSVRecord.java
index 979119f..2be5c49 100644
--- a/src/main/java/org/apache/commons/csv/CSVRecord.java
+++ b/src/main/java/org/apache/commons/csv/CSVRecord.java
@@ -199,7 +199,7 @@ public class CSVRecord implements Serializable,
Iterable {
 public final CSVRecord immutable() {
if (isMutable()) {
// Subclass is probably CSVMutableRecord, freeze values
-   String[] frozenValue = Arrays.copyOf(values, values.length);
+   String[] frozenValue = values.clone();
return new CSVRecord(frozenValue, mapping, comment,
recordNumber, characterPosition);
} else {
return this;
@@ -260,7 +260,7 @@ public class CSVRecord implements Serializable,
Iterable {
if (isMutable()) {
return this;
}
-   String[] newValues = Arrays.copyOf(values, values.length);
+   String[] newValues = values.clone();
return new CSVMutableRecord(newValues, mapping, comment,
recordNumber, characterPosition);
}



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

Discussion: New commons module/project

[Claude Warren]

Disclaimer:  I am not certain of the proper nomenclature to use here so
when I say module consider that it may be a sub-project or project under
commons.  The term should be taken to mean a collection of the things under
discussion.

I would like to propose a commons module for the development and
documentation of algorithms.  As anyone who has tried can attest, writing
specifications that are not misunderstood is nigh on impossible.  This
module would provide an area to discuss various algorithms and work out
code examples in various languages for implementation.

For example: Bloom Filters.  When creating a bloom filter you take the
modulus of a digest to determine which bit in a bit vector to turn on.  But
the modulus of a negative number is negative.  So is it proper to take the
absolute value (abs)  of the modulus or the digest or are you required to
consider the digest to be a very long unsigned integer?  All of these
choices have repercussions and may impact interoperability.

I have several co-workers and friends that are interested in exploring
algorithms of this sort.  Is there any interest here in starting such
discussions?  If so how does one go about it?

I would like to see a ticketing system (Jira?) that discussions could be
conducted against.  So, for example, a single ticket for bloom filter
implementation.  The ticket would stay open until consensus was achieved.
Once achieved the result would be documented and references to the
discussion provided.

Not clear on where to document the results and whether or not that
documentation would include code.

Thoughts?
Claude


-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: Discussion: New commons module/project

[Bernd Eckenfels]

Hello,

I am not sure how this might turn out, is it only discussion or do you also 
want to develop a specification language/toolset? In either case it does not 
sound like the typical commons sub-project. What infrastructure would you 
require?

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Claude Warren 
Sent: Tuesday, February 13, 2018 10:36:55 AM
To: Commons Developers List
Subject: Discussion: New commons module/project

Disclaimer:  I am not certain of the proper nomenclature to use here so
when I say module consider that it may be a sub-project or project under
commons.  The term should be taken to mean a collection of the things under
discussion.

I would like to propose a commons module for the development and
documentation of algorithms.  As anyone who has tried can attest, writing
specifications that are not misunderstood is nigh on impossible.  This
module would provide an area to discuss various algorithms and work out
code examples in various languages for implementation.

For example: Bloom Filters.  When creating a bloom filter you take the
modulus of a digest to determine which bit in a bit vector to turn on.  But
the modulus of a negative number is negative.  So is it proper to take the
absolute value (abs)  of the modulus or the digest or are you required to
consider the digest to be a very long unsigned integer?  All of these
choices have repercussions and may impact interoperability.

I have several co-workers and friends that are interested in exploring
algorithms of this sort.  Is there any interest here in starting such
discussions?  If so how does one go about it?

I would like to see a ticketing system (Jira?) that discussions could be
conducted against.  So, for example, a single ticket for bloom filter
implementation.  The ticket would stay open until consensus was achieved.
Once achieved the result would be documented and references to the
discussion provided.

Not clear on where to document the results and whether or not that
documentation would include code.

Thoughts?
Claude


--
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

JDK 10: First Release Candidate - JDK 10 b43

[Rory O'Donnell]

   Hi Benedikt,

*JDK 10 build 43 is our first JDK 10 Release Candidate [1]*

 * JDK 10 Early Access  build 43 is available at : - jdk.java.net/10/

Notable changes since previous email.**

*build 43
*

 * JDK-8194764  -
   javac incorrectly flags deprecated for removal imports
 * JDK-8196678  -
   avoid printing uninitialized buffer in os::print_memory_info on AIX
 * JDK-8195837  -
   (tz) Upgrade time-zone data to tzdata2018c

**

*Bug fixes reported by Open Source Projects  :*

 * JDK-8196296 
   Lucene test crashes C2 compilation

*Security Manager Survey
*

If you have written or maintain code that uses the SecurityManager or 
related APIs such as the AccessController,
then we would appreciate if you would complete this survey: 
https://www.surveymonkey.com/r/RSGMF3K

More info on the survey  [2]


Regards,
Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000742.html
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000649.html

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: Discussion: New commons module/project

[Claude Warren]

The goal is arrive at a common understanding of the specific algorithm and
potentially one or more code examples for implementation which may be
pseudo code.

I think all this requires is:

   1.  jira (or similar) to track the discussions and mark them when they
   are closed
   2. A mechanism to list the algorithms that have been or are under
   discussion.  Perhaps the Jira search could provide this by default.
   3. A repository for code snippets.  Though again perhaps Jira would be
   sufficient.
   4. Mailing list in order to take votes and the like.

Claude



On Tue, Feb 13, 2018 at 10:31 AM, Bernd Eckenfels 
wrote:

> Hello,
>
> I am not sure how this might turn out, is it only discussion or do you
> also want to develop a specification language/toolset? In either case it
> does not sound like the typical commons sub-project. What infrastructure
> would you require?
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Claude Warren 
> Sent: Tuesday, February 13, 2018 10:36:55 AM
> To: Commons Developers List
> Subject: Discussion: New commons module/project
>
> Disclaimer:  I am not certain of the proper nomenclature to use here so
> when I say module consider that it may be a sub-project or project under
> commons.  The term should be taken to mean a collection of the things under
> discussion.
>
> I would like to propose a commons module for the development and
> documentation of algorithms.  As anyone who has tried can attest, writing
> specifications that are not misunderstood is nigh on impossible.  This
> module would provide an area to discuss various algorithms and work out
> code examples in various languages for implementation.
>
> For example: Bloom Filters.  When creating a bloom filter you take the
> modulus of a digest to determine which bit in a bit vector to turn on.  But
> the modulus of a negative number is negative.  So is it proper to take the
> absolute value (abs)  of the modulus or the digest or are you required to
> consider the digest to be a very long unsigned integer?  All of these
> choices have repercussions and may impact interoperability.
>
> I have several co-workers and friends that are interested in exploring
> algorithms of this sort.  Is there any interest here in starting such
> discussions?  If so how does one go about it?
>
> I would like to see a ticketing system (Jira?) that discussions could be
> conducted against.  So, for example, a single ticket for bloom filter
> implementation.  The ticket would stay open until consensus was achieved.
> Once achieved the result would be documented and references to the
> discussion provided.
>
> Not clear on where to document the results and whether or not that
> documentation would include code.
>
> Thoughts?
> Claude
>
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren
>



-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: Discussion: New commons module/project

[Bruno P. Kinoshita]

Hi Claude,

Quite sure there was similar discussion some time ago. But I can't recall if it 
was here in commons, somewhere in the incubator, or labs?

But regarding commons, before the component/jira/mailing list are created, I 
think it would have to go either via sandbox or incubator first?


Perhaps having some code somewhere like GitHub to show more or less the concept 
would make it easier for others to evaluate the idea?
Cheers
Bruno






From: Claude Warren 
To: Commons Developers List  
Sent: Tuesday, 13 February 2018 11:55 PM
Subject: Re: Discussion: New commons module/project



The goal is arrive at a common understanding of the specific algorithm and
potentially one or more code examples for implementation which may be
pseudo code.

I think all this requires is:

   1.  jira (or similar) to track the discussions and mark them when they
   are closed
   2. A mechanism to list the algorithms that have been or are under
   discussion.  Perhaps the Jira search could provide this by default.
   3. A repository for code snippets.  Though again perhaps Jira would be
   sufficient.
   4. Mailing list in order to take votes and the like.

Claude



On Tue, Feb 13, 2018 at 10:31 AM, Bernd Eckenfels 
wrote:

> Hello,
>
> I am not sure how this might turn out, is it only discussion or do you
> also want to develop a specification language/toolset? In either case it
> does not sound like the typical commons sub-project. What infrastructure
> would you require?
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Claude Warren 
> Sent: Tuesday, February 13, 2018 10:36:55 AM
> To: Commons Developers List
> Subject: Discussion: New commons module/project
>
> Disclaimer:  I am not certain of the proper nomenclature to use here so
> when I say module consider that it may be a sub-project or project under
> commons.  The term should be taken to mean a collection of the things under
> discussion.
>
> I would like to propose a commons module for the development and
> documentation of algorithms.  As anyone who has tried can attest, writing
> specifications that are not misunderstood is nigh on impossible.  This
> module would provide an area to discuss various algorithms and work out
> code examples in various languages for implementation.
>
> For example: Bloom Filters.  When creating a bloom filter you take the
> modulus of a digest to determine which bit in a bit vector to turn on.  But
> the modulus of a negative number is negative.  So is it proper to take the
> absolute value (abs)  of the modulus or the digest or are you required to
> consider the digest to be a very long unsigned integer?  All of these
> choices have repercussions and may impact interoperability.
>
> I have several co-workers and friends that are interested in exploring
> algorithms of this sort.  Is there any interest here in starting such
> discussions?  If so how does one go about it?
>
> I would like to see a ticketing system (Jira?) that discussions could be
> conducted against.  So, for example, a single ticket for bloom filter
> implementation.  The ticket would stay open until consensus was achieved.
> Once achieved the result would be documented and references to the
> discussion provided.
>
> Not clear on where to document the results and whether or not that
> documentation would include code.
>
> Thoughts?
> Claude
>
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren

>



-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

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

Re: [text] Adapt the Log4j 2 Interpolator to [text]

[Pascal Schumacher]

Am 12.02.2018 um 21:53 schrieb Gary Gregory:

On Mon, Feb 12, 2018 at 12:53 PM, Gary Gregory 
wrote:


On Mon, Feb 12, 2018 at 12:30 PM, Pascal Schumacher <
pascalschumac...@gmx.net> wrote:


please revert "Update actual Checkstyle from 6.19 to 8.8.", as Checkstyle
7+ requries Java 8+.


Done.


Thanks!

and please fix the findbugs violation:

[INFO] --- findbugs-maven-plugin:3.0.5:check(default-cli)@
commons-text---
[INFO] BugInstance size is 1
[INFO] Error size is 0
[INFO] Total bugs: 1
[INFO] org.apache.commons.text.StringTokenizer.clone() does not call
super.clone() [org.apache.commons.text.StringTokenizer] At
StringTokenizer.java:[lines 1138-1140] CN_IDIOM_NO_SUPER_CALL


But super.clone() is called, from another method...


And findbugs does not complain about the same code in StrTokenizer. What?


For StrTokenizer there is an exclusion in fb-excludes.xml.

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

Re: commons-csv git commit: CSV-216: Avoid Arrays.copyOf()

[sebb]

On 13 February 2018 at 09:31, Gilles  wrote:
> On Tue, 13 Feb 2018 00:16:13 + (UTC), st...@apache.org wrote:
>>
>> Repository: commons-csv
>> Updated Branches:
>>   refs/heads/CSV-216 637ad2d7a -> f66a83901
>>
>>
>> CSV-216: Avoid Arrays.copyOf()
>
>
> Why?

Agreed

>> as .clone() will do
>
>
> We should rather avoid using "clone()".

Again: why?

It's not clear why Arrays.copyOf(0 is considered bad, nor why clone()
is considered bad.

> Gilles
>
>
>> -- at least until someone tries to do
>> .withValue(x) in an out-of-range column
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/commons-csv/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/commons-csv/commit/f66a8390
>> Tree: http://git-wip-us.apache.org/repos/asf/commons-csv/tree/f66a8390
>> Diff: http://git-wip-us.apache.org/repos/asf/commons-csv/diff/f66a8390
>>
>> Branch: refs/heads/CSV-216
>> Commit: f66a83901bd026369a2e8d522bd567eb2ef3f8c0
>> Parents: 637ad2d
>> Author: Stian Soiland-Reyes 
>> Authored: Fri Feb 9 16:49:51 2018 +
>> Committer: Stian Soiland-Reyes 
>> Committed: Tue Feb 13 00:14:52 2018 +
>>
>>
>> --
>>  src/main/java/org/apache/commons/csv/CSVRecord.java | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> --
>>
>>
>>
>>
>> http://git-wip-us.apache.org/repos/asf/commons-csv/blob/f66a8390/src/main/java/org/apache/commons/csv/CSVRecord.java
>>
>> --
>> diff --git a/src/main/java/org/apache/commons/csv/CSVRecord.java
>> b/src/main/java/org/apache/commons/csv/CSVRecord.java
>> index 979119f..2be5c49 100644
>> --- a/src/main/java/org/apache/commons/csv/CSVRecord.java
>> +++ b/src/main/java/org/apache/commons/csv/CSVRecord.java
>> @@ -199,7 +199,7 @@ public class CSVRecord implements Serializable,
>> Iterable {
>>  public final CSVRecord immutable() {
>> if (isMutable()) {
>> // Subclass is probably CSVMutableRecord, freeze values
>> -   String[] frozenValue = Arrays.copyOf(values,
>> values.length);
>> +   String[] frozenValue = values.clone();
>> return new CSVRecord(frozenValue, mapping, comment,
>> recordNumber, characterPosition);
>> } else {
>> return this;
>> @@ -260,7 +260,7 @@ public class CSVRecord implements Serializable,
>> Iterable {
>> if (isMutable()) {
>> return this;
>> }
>> -   String[] newValues = Arrays.copyOf(values, values.length);
>> +   String[] newValues = values.clone();
>> return new CSVMutableRecord(newValues, mapping, comment,
>> recordNumber, characterPosition);
>> }
>
>
>
> -
> 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: commons-csv git commit: CSV-216: Avoid Arrays.copyOf()

[Gilles]

On Tue, 13 Feb 2018 18:40:13 +, sebb wrote:
On 13 February 2018 at 09:31, Gilles  
wrote:

On Tue, 13 Feb 2018 00:16:13 + (UTC), st...@apache.org wrote:


Repository: commons-csv
Updated Branches:
  refs/heads/CSV-216 637ad2d7a -> f66a83901


CSV-216: Avoid Arrays.copyOf()



Why?


Agreed


as .clone() will do



We should rather avoid using "clone()".


Again: why?


There are many discussions about this topic on the web.[1]
My point is that using "clone()" is not good advice.

Gilles

[1] E.g. http://vojtechruzicka.com/java-cloning-problems/


It's not clear why Arrays.copyOf(0 is considered bad, nor why clone()
is considered bad.



Gilles



-- at least until someone tries to do
.withValue(x) in an out-of-range column


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


Branch: refs/heads/CSV-216
Commit: f66a83901bd026369a2e8d522bd567eb2ef3f8c0
Parents: 637ad2d
Author: Stian Soiland-Reyes 
Authored: Fri Feb 9 16:49:51 2018 +
Committer: Stian Soiland-Reyes 
Committed: Tue Feb 13 00:14:52 2018 +



--
 src/main/java/org/apache/commons/csv/CSVRecord.java | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


--





http://git-wip-us.apache.org/repos/asf/commons-csv/blob/f66a8390/src/main/java/org/apache/commons/csv/CSVRecord.java


--
diff --git a/src/main/java/org/apache/commons/csv/CSVRecord.java
b/src/main/java/org/apache/commons/csv/CSVRecord.java
index 979119f..2be5c49 100644
--- a/src/main/java/org/apache/commons/csv/CSVRecord.java
+++ b/src/main/java/org/apache/commons/csv/CSVRecord.java
@@ -199,7 +199,7 @@ public class CSVRecord implements Serializable,
Iterable {
 public final CSVRecord immutable() {
if (isMutable()) {
// Subclass is probably CSVMutableRecord, freeze 
values

-   String[] frozenValue = Arrays.copyOf(values,
values.length);
+   String[] frozenValue = values.clone();
return new CSVRecord(frozenValue, mapping, comment,
recordNumber, characterPosition);
} else {
return this;
@@ -260,7 +260,7 @@ public class CSVRecord implements Serializable,
Iterable {
if (isMutable()) {
return this;
}
-   String[] newValues = Arrays.copyOf(values, 
values.length);

+   String[] newValues = values.clone();
return new CSVMutableRecord(newValues, mapping, comment,
recordNumber, characterPosition);
}



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

Re: Discussion: New commons module/project

[Matt Sicker]

A sort of commons-algorithms type library? That kind of strikes me as what
Commons is in the first place. I could see it being broken down into
components, though. For example, commons-graph <
https://commons.apache.org/sandbox/commons-graph/> (seems inactive) for
graph algorithms, commons-tree for trees, heaps, and other similar ADTs and
algorithms. Some ADTs already belong in commons-collections. Some
algorithms may already be in commons-math, and there's efforts toward
splitting that up into individual components (e.g., rng, numbers,
statistics), so it doesn't make sense to group them in there IMO.

On 13 February 2018 at 05:23, Bruno P. Kinoshita <
brunodepau...@yahoo.com.br.invalid> wrote:

> Hi Claude,
>
> Quite sure there was similar discussion some time ago. But I can't recall
> if it was here in commons, somewhere in the incubator, or labs?
>
> But regarding commons, before the component/jira/mailing list are created,
> I think it would have to go either via sandbox or incubator first?
>
>
> Perhaps having some code somewhere like GitHub to show more or less the
> concept would make it easier for others to evaluate the idea?
> Cheers
> Bruno
>
>
>
>
>
> 
> From: Claude Warren 
> To: Commons Developers List 
> Sent: Tuesday, 13 February 2018 11:55 PM
> Subject: Re: Discussion: New commons module/project
>
>
>
> The goal is arrive at a common understanding of the specific algorithm and
> potentially one or more code examples for implementation which may be
> pseudo code.
>
> I think all this requires is:
>
>1.  jira (or similar) to track the discussions and mark them when they
>are closed
>2. A mechanism to list the algorithms that have been or are under
>discussion.  Perhaps the Jira search could provide this by default.
>3. A repository for code snippets.  Though again perhaps Jira would be
>sufficient.
>4. Mailing list in order to take votes and the like.
>
> Claude
>
>
>
> On Tue, Feb 13, 2018 at 10:31 AM, Bernd Eckenfels 
> wrote:
>
> > Hello,
> >
> > I am not sure how this might turn out, is it only discussion or do you
> > also want to develop a specification language/toolset? In either case it
> > does not sound like the typical commons sub-project. What infrastructure
> > would you require?
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > 
> > From: Claude Warren 
> > Sent: Tuesday, February 13, 2018 10:36:55 AM
> > To: Commons Developers List
> > Subject: Discussion: New commons module/project
> >
> > Disclaimer:  I am not certain of the proper nomenclature to use here so
> > when I say module consider that it may be a sub-project or project under
> > commons.  The term should be taken to mean a collection of the things
> under
> > discussion.
> >
> > I would like to propose a commons module for the development and
> > documentation of algorithms.  As anyone who has tried can attest, writing
> > specifications that are not misunderstood is nigh on impossible.  This
> > module would provide an area to discuss various algorithms and work out
> > code examples in various languages for implementation.
> >
> > For example: Bloom Filters.  When creating a bloom filter you take the
> > modulus of a digest to determine which bit in a bit vector to turn on.
> But
> > the modulus of a negative number is negative.  So is it proper to take
> the
> > absolute value (abs)  of the modulus or the digest or are you required to
> > consider the digest to be a very long unsigned integer?  All of these
> > choices have repercussions and may impact interoperability.
> >
> > I have several co-workers and friends that are interested in exploring
> > algorithms of this sort.  Is there any interest here in starting such
> > discussions?  If so how does one go about it?
> >
> > I would like to see a ticketing system (Jira?) that discussions could be
> > conducted against.  So, for example, a single ticket for bloom filter
> > implementation.  The ticket would stay open until consensus was achieved.
> > Once achieved the result would be documented and references to the
> > discussion provided.
> >
> > Not clear on where to document the results and whether or not that
> > documentation would include code.
> >
> > Thoughts?
> > Claude
> >
> >
> > --
> > I like: Like Like - The likeliest place on the web
> > 
> > LinkedIn: http://www.linkedin.com/in/claudewarren
>
> >
>
>
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Matt Sicker 

Re: [text] Adapt the Log4j 2 Interpolator to [text]

[Gary Gregory]

On Tue, Feb 13, 2018 at 11:06 AM, Pascal Schumacher <
pascalschumac...@gmx.net> wrote:

> Am 12.02.2018 um 21:53 schrieb Gary Gregory:
>
>> On Mon, Feb 12, 2018 at 12:53 PM, Gary Gregory 
>> wrote:
>>
>> On Mon, Feb 12, 2018 at 12:30 PM, Pascal Schumacher <
>>> pascalschumac...@gmx.net> wrote:
>>>
>>> please revert "Update actual Checkstyle from 6.19 to 8.8.", as Checkstyle
 7+ requries Java 8+.

 Done.
>>>
>>
> Thanks!
>
>> and please fix the findbugs violation:

 [INFO] --- findbugs-maven-plugin:3.0.5:check(default-cli)@
 commons-text---
 [INFO] BugInstance size is 1
 [INFO] Error size is 0
 [INFO] Total bugs: 1
 [INFO] org.apache.commons.text.StringTokenizer.clone() does not call
 super.clone() [org.apache.commons.text.StringTokenizer] At
 StringTokenizer.java:[lines 1138-1140] CN_IDIOM_NO_SUPER_CALL

 But super.clone() is called, from another method...
>>>
>>> And findbugs does not complain about the same code in StrTokenizer. What?
>>
>
> For StrTokenizer there is an exclusion in fb-excludes.xml.


Thank you for the pointer. I updated the FB exclusion file to do the same
for org.apache.commons.text.StringTokenizer.

Gary


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

Re: [text] Update from Java 7 to Java 8?

[Gary Gregory]

On Mon, Feb 12, 2018 at 1:03 PM, Pascal Schumacher  wrote:

> What about now? :-)
>

Fine with me. Let's see if anyone objects...

Gary


>
> Am 12.02.2018 um 20:53 schrieb Gary Gregory:
>
>> When?
>>
>> Gary
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [text] Update from Java 7 to Java 8?

[Gary Gregory]

On Tue, Feb 13, 2018 at 3:13 PM, Gary Gregory 
wrote:

> On Mon, Feb 12, 2018 at 1:03 PM, Pascal Schumacher <
> pascalschumac...@gmx.net> wrote:
>
>> What about now? :-)
>>
>
> Fine with me. Let's see if anyone objects...
>

What about:

- Release 1.3 as is WRT Java, which is Java 7
- Switch to Java 8 for 1.4.

Gary


>
> Gary
>
>
>>
>> Am 12.02.2018 um 20:53 schrieb Gary Gregory:
>>
>>> When?
>>>
>>> Gary
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>

Re: [text] Update from Java 7 to Java 8?

[Pascal Schumacher]

Am 13.02.2018 um 23:14 schrieb Gary Gregory:

What about:

- Release 1.3 as is WRT Java, which is Java 7
- Switch to Java 8 for 1.4.


Fine with me.

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

[All][RNG] Java 9 ready?

[Gilles]

Hi.

Some enhancements are needed to the build "infrastructure"
(CP, maven plugins, multi-module layout) in order for the
"Commons" artefacts to be used fully as "modules" under
Java 9 and beyond.

See my last comment in
  https://issues.apache.org/jira/browse/RNG-40

Regards,
Gilles



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

Re: Discussion: New commons module/project

[Ralph Goers]

If this was a project to create specs AND provide reference implementations I 
think it would make sense. I don’t see how a project that just creates specs 
fits with Commons personally. 

Ralph

> On Feb 13, 2018, at 1:46 PM, Matt Sicker  wrote:
> 
> A sort of commons-algorithms type library? That kind of strikes me as what
> Commons is in the first place. I could see it being broken down into
> components, though. For example, commons-graph <
> https://commons.apache.org/sandbox/commons-graph/> (seems inactive) for
> graph algorithms, commons-tree for trees, heaps, and other similar ADTs and
> algorithms. Some ADTs already belong in commons-collections. Some
> algorithms may already be in commons-math, and there's efforts toward
> splitting that up into individual components (e.g., rng, numbers,
> statistics), so it doesn't make sense to group them in there IMO.
> 
> On 13 February 2018 at 05:23, Bruno P. Kinoshita <
> brunodepau...@yahoo.com.br.invalid> wrote:
> 
>> Hi Claude,
>> 
>> Quite sure there was similar discussion some time ago. But I can't recall
>> if it was here in commons, somewhere in the incubator, or labs?
>> 
>> But regarding commons, before the component/jira/mailing list are created,
>> I think it would have to go either via sandbox or incubator first?
>> 
>> 
>> Perhaps having some code somewhere like GitHub to show more or less the
>> concept would make it easier for others to evaluate the idea?
>> Cheers
>> Bruno
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Claude Warren 
>> To: Commons Developers List 
>> Sent: Tuesday, 13 February 2018 11:55 PM
>> Subject: Re: Discussion: New commons module/project
>> 
>> 
>> 
>> The goal is arrive at a common understanding of the specific algorithm and
>> potentially one or more code examples for implementation which may be
>> pseudo code.
>> 
>> I think all this requires is:
>> 
>>   1.  jira (or similar) to track the discussions and mark them when they
>>   are closed
>>   2. A mechanism to list the algorithms that have been or are under
>>   discussion.  Perhaps the Jira search could provide this by default.
>>   3. A repository for code snippets.  Though again perhaps Jira would be
>>   sufficient.
>>   4. Mailing list in order to take votes and the like.
>> 
>> Claude
>> 
>> 
>> 
>> On Tue, Feb 13, 2018 at 10:31 AM, Bernd Eckenfels 
>> wrote:
>> 
>>> Hello,
>>> 
>>> I am not sure how this might turn out, is it only discussion or do you
>>> also want to develop a specification language/toolset? In either case it
>>> does not sound like the typical commons sub-project. What infrastructure
>>> would you require?
>>> 
>>> Gruss
>>> Bernd
>>> --
>>> http://bernd.eckenfels.net
>>> 
>>> From: Claude Warren 
>>> Sent: Tuesday, February 13, 2018 10:36:55 AM
>>> To: Commons Developers List
>>> Subject: Discussion: New commons module/project
>>> 
>>> Disclaimer:  I am not certain of the proper nomenclature to use here so
>>> when I say module consider that it may be a sub-project or project under
>>> commons.  The term should be taken to mean a collection of the things
>> under
>>> discussion.
>>> 
>>> I would like to propose a commons module for the development and
>>> documentation of algorithms.  As anyone who has tried can attest, writing
>>> specifications that are not misunderstood is nigh on impossible.  This
>>> module would provide an area to discuss various algorithms and work out
>>> code examples in various languages for implementation.
>>> 
>>> For example: Bloom Filters.  When creating a bloom filter you take the
>>> modulus of a digest to determine which bit in a bit vector to turn on.
>> But
>>> the modulus of a negative number is negative.  So is it proper to take
>> the
>>> absolute value (abs)  of the modulus or the digest or are you required to
>>> consider the digest to be a very long unsigned integer?  All of these
>>> choices have repercussions and may impact interoperability.
>>> 
>>> I have several co-workers and friends that are interested in exploring
>>> algorithms of this sort.  Is there any interest here in starting such
>>> discussions?  If so how does one go about it?
>>> 
>>> I would like to see a ticketing system (Jira?) that discussions could be
>>> conducted against.  So, for example, a single ticket for bloom filter
>>> implementation.  The ticket would stay open until consensus was achieved.
>>> Once achieved the result would be documented and references to the
>>> discussion provided.
>>> 
>>> Not clear on where to document the results and whether or not that
>>> documentation would include code.
>>> 
>>> Thoughts?
>>> Claude
>>> 
>>> 
>>> --
>>> I like: Like Like - The likeliest place on the web
>>> 
>>> LinkedIn: http://www.linkedin.com/in/claudewarren
>> 
>>> 
>> 
>> 
>> 
>> --
>> I like: Like Like - The likeliest place on the web
>> 
>> LinkedIn: http://www.linkedin.com/in/claudewarren
>> 
>> --

Re: Discussion: New commons module/project

[Charles Honton]

What can / does commons provide that cannot be done with GitHub?

chas

> On Feb 13, 2018, at 5:58 PM, Ralph Goers  wrote:
> 
> If this was a project to create specs AND provide reference implementations I 
> think it would make sense. I don’t see how a project that just creates specs 
> fits with Commons personally. 
> 
> Ralph
> 
>> On Feb 13, 2018, at 1:46 PM, Matt Sicker  wrote:
>> 
>> A sort of commons-algorithms type library? That kind of strikes me as what
>> Commons is in the first place. I could see it being broken down into
>> components, though. For example, commons-graph <
>> https://commons.apache.org/sandbox/commons-graph/> (seems inactive) for
>> graph algorithms, commons-tree for trees, heaps, and other similar ADTs and
>> algorithms. Some ADTs already belong in commons-collections. Some
>> algorithms may already be in commons-math, and there's efforts toward
>> splitting that up into individual components (e.g., rng, numbers,
>> statistics), so it doesn't make sense to group them in there IMO.
>> 
>> On 13 February 2018 at 05:23, Bruno P. Kinoshita <
>> brunodepau...@yahoo.com.br.invalid> wrote:
>> 
>>> Hi Claude,
>>> 
>>> Quite sure there was similar discussion some time ago. But I can't recall
>>> if it was here in commons, somewhere in the incubator, or labs?
>>> 
>>> But regarding commons, before the component/jira/mailing list are created,
>>> I think it would have to go either via sandbox or incubator first?
>>> 
>>> 
>>> Perhaps having some code somewhere like GitHub to show more or less the
>>> concept would make it easier for others to evaluate the idea?
>>> Cheers
>>> Bruno
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> From: Claude Warren 
>>> To: Commons Developers List 
>>> Sent: Tuesday, 13 February 2018 11:55 PM
>>> Subject: Re: Discussion: New commons module/project
>>> 
>>> 
>>> 
>>> The goal is arrive at a common understanding of the specific algorithm and
>>> potentially one or more code examples for implementation which may be
>>> pseudo code.
>>> 
>>> I think all this requires is:
>>> 
>>>  1.  jira (or similar) to track the discussions and mark them when they
>>>  are closed
>>>  2. A mechanism to list the algorithms that have been or are under
>>>  discussion.  Perhaps the Jira search could provide this by default.
>>>  3. A repository for code snippets.  Though again perhaps Jira would be
>>>  sufficient.
>>>  4. Mailing list in order to take votes and the like.
>>> 
>>> Claude
>>> 
>>> 
>>> 
>>> On Tue, Feb 13, 2018 at 10:31 AM, Bernd Eckenfels 
>>> wrote:
>>> 
 Hello,
 
 I am not sure how this might turn out, is it only discussion or do you
 also want to develop a specification language/toolset? In either case it
 does not sound like the typical commons sub-project. What infrastructure
 would you require?
 
 Gruss
 Bernd
 --
 http://bernd.eckenfels.net
 
 From: Claude Warren 
 Sent: Tuesday, February 13, 2018 10:36:55 AM
 To: Commons Developers List
 Subject: Discussion: New commons module/project
 
 Disclaimer:  I am not certain of the proper nomenclature to use here so
 when I say module consider that it may be a sub-project or project under
 commons.  The term should be taken to mean a collection of the things
>>> under
 discussion.
 
 I would like to propose a commons module for the development and
 documentation of algorithms.  As anyone who has tried can attest, writing
 specifications that are not misunderstood is nigh on impossible.  This
 module would provide an area to discuss various algorithms and work out
 code examples in various languages for implementation.
 
 For example: Bloom Filters.  When creating a bloom filter you take the
 modulus of a digest to determine which bit in a bit vector to turn on.
>>> But
 the modulus of a negative number is negative.  So is it proper to take
>>> the
 absolute value (abs)  of the modulus or the digest or are you required to
 consider the digest to be a very long unsigned integer?  All of these
 choices have repercussions and may impact interoperability.
 
 I have several co-workers and friends that are interested in exploring
 algorithms of this sort.  Is there any interest here in starting such
 discussions?  If so how does one go about it?
 
 I would like to see a ticketing system (Jira?) that discussions could be
 conducted against.  So, for example, a single ticket for bloom filter
 implementation.  The ticket would stay open until consensus was achieved.
 Once achieved the result would be documented and references to the
 discussion provided.
 
 Not clear on where to document the results and whether or not that
 documentation would include code.
 
 Thoughts?
 Claude
 
 
 --
 I like: Like Like - The likeliest place on the web