[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable

2018-02-14 Thread stain
Github user stain commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
You may have better ideas on how to do something like 
[ParserConfigImpl](https://github.com/apache/commons-rdf/blob/fluent-parser/commons-rdf-api/src/main/java/org/apache/commons/rdf/api/io/ParserConfigImpl.java)
 so it is serializable.  For instance the 
[ParserSource](https://github.com/apache/commons-rdf/blob/fluent-parser/commons-rdf-api/src/main/java/org/apache/commons/rdf/api/io/ParserSource.java)
 beans might or might not be serializable depending on the implementation.

(Surely one that is just connected to an open InputStream is not 
serializable, but one that has just got an IRI should be serializable. I made 
the implementations package private: 
[IRIParserSource](https://github.com/apache/commons-rdf/blob/fluent-parser/commons-rdf-api/src/main/java/org/apache/commons/rdf/api/io/IRIParserSource.java)
 which meant I had to make a new 
[IRIImpl](https://github.com/apache/commons-rdf/blob/fluent-parser/commons-rdf-api/src/main/java/org/apache/commons/rdf/api/io/IRIImpl.java)
 to avoid Simple dependency)


---

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



[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable

2018-02-14 Thread stain
Github user stain commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
Thanks, @ajs6f !

I found some old code where I had tried to make a fluent interface.. I 
managed to update it to the current master and sorted some issues.

I pushed it to the `fluent-parser` branch

See https://github.com/apache/commons-rdf/compare/fluent-parser 

I haven't implemented the `Parser` yet or written any tests.

Basically the idea is this:

```java
  Parsed p = rdf.parserBuilder()
  .syntax(RDFSyntax.JSONLD)
  .source("http://example.com/data.jsonld;)
  .parse();
```

or:

```java
rdf.parserBuilder()
  .syntax(RDFSyntax.TURTLE)
  .target(quad -> System.out.println(quad.getSubject()))  
  .source(Paths.get("/tmp/file.ttl").
  .async().parseAsync();
```

Now there is a set of interfaces, one for each step along the way, e.g. 
`NeedTarget`, and 
some internal `_` package interfaces to ensure consistency (but this can be 
flattened). Note that it is easier in this code to explore this in Eclipse with 
auto-complete as the interfaces have not been flattened yet.

It is implemented by a single `AbstractParserBuilder` which keeps all its 
state (except async executor) in a `ParserConfig` bean. The builder can be made 
immutable using `.build()` after which any change will make it mutable again.  
While it's mutable it will mutate the bean without any copies.

There is also a more low-level `Parser` which takes a `ParserConfig` - this 
is basically how the RDF implementations can be invoked.

I have not moved over the preflight checks in AbstractRDFParser there.

Feel free to use it as a starting ground or inspiration! It's quite hard to 
do fluent interfaces..


---

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



Re: [text] LocalHostStringLookupTest: correct order of assertEquals arguments

2018-02-14 Thread Pascal Schumacher

You are welcome!

-Pascal

Am 14.02.2018 um 21:31 schrieb Gary Gregory:

Good catch Pascal, thank you!

Gary

On Wed, Feb 14, 2018 at 12:59 PM,  wrote:


Repository: commons-text
Updated Branches:
   refs/heads/master fb5d8c93a -> 6e9107dc8


LocalHostStringLookupTest: correct order of assertEquals arguments


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

Branch: refs/heads/master
Commit: 6e9107dc826cee43629af6a3857c98c90da18eba
Parents: fb5d8c9
Author: Pascal Schumacher 
Authored: Wed Feb 14 20:58:41 2018 +0100
Committer: Pascal Schumacher 
Committed: Wed Feb 14 20:58:41 2018 +0100

--
  .../commons/text/lookup/LocalHostStringLookupTest.java   | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/commons-text/blob/
6e9107dc/src/test/java/org/apache/commons/text/lookup/
LocalHostStringLookupTest.java
--
diff --git 
a/src/test/java/org/apache/commons/text/lookup/LocalHostStringLookupTest.java
b/src/test/java/org/apache/commons/text/lookup/
LocalHostStringLookupTest.java
index ffcaf1c..c00a7dc 100644
--- a/src/test/java/org/apache/commons/text/lookup/
LocalHostStringLookupTest.java
+++ b/src/test/java/org/apache/commons/text/lookup/
LocalHostStringLookupTest.java
@@ -27,19 +27,20 @@ public class LocalHostStringLookupTest {

  @Test
  public void testAddress() throws UnknownHostException {
-Assert.assertEquals(LocalHostStringLookup.
INSTANCE.lookup("address"),
-InetAddress.getLocalHost().getHostAddress());
+Assert.assertEquals(InetAddress.getLocalHost().getHostAddress(),
+LocalHostStringLookup.INSTANCE.lookup("address"));
  }

  @Test
  public void testCanonicalName() throws UnknownHostException {
-Assert.assertEquals(LocalHostStringLookup.
INSTANCE.lookup("canonical-name"),
-InetAddress.getLocalHost().getCanonicalHostName());
+Assert.assertEquals(InetAddress.getLocalHost().
getCanonicalHostName(),
+LocalHostStringLookup.INSTANCE.lookup("canonical-name"));
  }

  @Test
  public void testName() throws UnknownHostException {
-Assert.assertEquals(LocalHostStringLookup.INSTANCE.lookup("name"),
InetAddress.getLocalHost().getHostName());
+Assert.assertEquals(InetAddress.getLocalHost().getHostName(),
+LocalHostStringLookup.INSTANCE.lookup("name"));
  }

  }





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



Re: [text] LocalHostStringLookupTest: correct order of assertEquals arguments

2018-02-14 Thread Gary Gregory
Good catch Pascal, thank you!

Gary

On Wed, Feb 14, 2018 at 12:59 PM,  wrote:

> Repository: commons-text
> Updated Branches:
>   refs/heads/master fb5d8c93a -> 6e9107dc8
>
>
> LocalHostStringLookupTest: correct order of assertEquals arguments
>
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-text/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-text/commit/
> 6e9107dc
> Tree: http://git-wip-us.apache.org/repos/asf/commons-text/tree/6e9107dc
> Diff: http://git-wip-us.apache.org/repos/asf/commons-text/diff/6e9107dc
>
> Branch: refs/heads/master
> Commit: 6e9107dc826cee43629af6a3857c98c90da18eba
> Parents: fb5d8c9
> Author: Pascal Schumacher 
> Authored: Wed Feb 14 20:58:41 2018 +0100
> Committer: Pascal Schumacher 
> Committed: Wed Feb 14 20:58:41 2018 +0100
>
> --
>  .../commons/text/lookup/LocalHostStringLookupTest.java   | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/commons-text/blob/
> 6e9107dc/src/test/java/org/apache/commons/text/lookup/
> LocalHostStringLookupTest.java
> --
> diff --git 
> a/src/test/java/org/apache/commons/text/lookup/LocalHostStringLookupTest.java
> b/src/test/java/org/apache/commons/text/lookup/
> LocalHostStringLookupTest.java
> index ffcaf1c..c00a7dc 100644
> --- a/src/test/java/org/apache/commons/text/lookup/
> LocalHostStringLookupTest.java
> +++ b/src/test/java/org/apache/commons/text/lookup/
> LocalHostStringLookupTest.java
> @@ -27,19 +27,20 @@ public class LocalHostStringLookupTest {
>
>  @Test
>  public void testAddress() throws UnknownHostException {
> -Assert.assertEquals(LocalHostStringLookup.
> INSTANCE.lookup("address"),
> -InetAddress.getLocalHost().getHostAddress());
> +Assert.assertEquals(InetAddress.getLocalHost().getHostAddress(),
> +LocalHostStringLookup.INSTANCE.lookup("address"));
>  }
>
>  @Test
>  public void testCanonicalName() throws UnknownHostException {
> -Assert.assertEquals(LocalHostStringLookup.
> INSTANCE.lookup("canonical-name"),
> -InetAddress.getLocalHost().getCanonicalHostName());
> +Assert.assertEquals(InetAddress.getLocalHost().
> getCanonicalHostName(),
> +LocalHostStringLookup.INSTANCE.lookup("canonical-name"));
>  }
>
>  @Test
>  public void testName() throws UnknownHostException {
> -Assert.assertEquals(LocalHostStringLookup.INSTANCE.lookup("name"),
> InetAddress.getLocalHost().getHostName());
> +Assert.assertEquals(InetAddress.getLocalHost().getHostName(),
> +LocalHostStringLookup.INSTANCE.lookup("name"));
>  }
>
>  }
>
>


Re: commons-release-plugin git commit: Add self.

2018-02-14 Thread Rob Tompkins


> On Feb 14, 2018, at 12:17 PM, Gary Gregory  wrote:
> 
>> On Wed, Feb 14, 2018 at 8:04 AM, Rob Tompkins  wrote:
>> 
>> Given the typographical errors, should we roll a 1.1?
>> 
> 
> Why not? :-) Meaning "Go for it" :-)

I’ll try to get to it tonight. 

> 
> Gary
> 
> 
>> 
>>> On Feb 14, 2018, at 9:45 AM, ggreg...@apache.org wrote:
>>> 
>>> Repository: commons-release-plugin
>>> Updated Branches:
>>> refs/heads/master efce48a13 -> 144b5ce3b
>>> 
>>> 
>>> Add self.
>>> 
>>> Project: http://git-wip-us.apache.org/repos/asf/commons-release-
>> plugin/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/commons-release-
>> plugin/commit/144b5ce3
>>> Tree: http://git-wip-us.apache.org/repos/asf/commons-release-
>> plugin/tree/144b5ce3
>>> Diff: http://git-wip-us.apache.org/repos/asf/commons-release-
>> plugin/diff/144b5ce3
>>> 
>>> Branch: refs/heads/master
>>> Commit: 144b5ce3bb36bed892666a5946bf5ba6fbcdbc9d
>>> Parents: efce48a
>>> Author: Gary Gregory 
>>> Authored: Wed Feb 14 07:45:47 2018 -0700
>>> Committer: Gary Gregory 
>>> Committed: Wed Feb 14 07:45:47 2018 -0700
>>> 
>>> --
>>> pom.xml | 6 ++
>>> 1 file changed, 6 insertions(+)
>>> --
>>> 
>>> 
>>> http://git-wip-us.apache.org/repos/asf/commons-release-
>> plugin/blob/144b5ce3/pom.xml
>>> --
>>> diff --git a/pom.xml b/pom.xml
>>> index 09432fb..ef35ed5 100644
>>> --- a/pom.xml
>>> +++ b/pom.xml
>>> @@ -63,6 +63,12 @@
>>>chtom...@apache.org
>>>-5
>>>
>>> +
>>> +Gary Gregory
>>> +ggregory
>>> +ggreg...@apache.org
>>> +-6
>>> +
>>>
>>> 
>>>
>>> 
>> 
>> 
>> -
>> 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



[GitHub] commons-text pull request #44: TEXT-80: Fixed confusing StrLookup API

2018-02-14 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/commons-text/pull/44


---

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



[GitHub] commons-text pull request #24: TEXT-25: Add a duration parser

2018-02-14 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/commons-text/pull/24


---

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



[GitHub] commons-text issue #44: TEXT-80: Fixed confusing StrLookup API

2018-02-14 Thread PascalSchumacher
Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-text/pull/44
  
I'm closing this as `StrLookup` will deprecated and replaced with 
`StringLookup` in the next release.


---

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



[GitHub] commons-rdf pull request #49: Cleanup for FindBugs and PMD warnings in -simp...

2018-02-14 Thread ajs6f
Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/commons-rdf/pull/49#discussion_r168275645
  
--- Diff: 
commons-rdf-simple/src/main/java/org/apache/commons/rdf/simple/experimental/AbstractRDFParser.java
 ---
@@ -58,8 +60,12 @@
  */
 public abstract class AbstractRDFParser> 
implements RDFParser, Cloneable {
 
-public static final ThreadGroup threadGroup = new ThreadGroup("Commons 
RDF parsers");
-private static final ExecutorService threadpool = 
Executors.newCachedThreadPool(r -> new Thread(threadGroup, r));
+public static final AtomicInteger threadCount = new AtomicInteger();
+private static Thread newThread(Runnable r) {
--- End diff --

That's why I put [the name "Commons RDF Parser 
"](https://github.com/apache/commons-rdf/pull/49/files/f1649e034a2623137434fcc2810f8802d3ee9434#diff-68c2acaf43f1ae22da0bdb4eac55a201R65)
 back in. But like I said, I am fine with whatever- I was just tearing through 
PMD warnings at speed after the comment (I think to the board report) about 
there being a lot of them. Shall I take your comment as a direction to remove 
this change? Happy to...


---

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



[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable

2018-02-14 Thread ajs6f
Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
Okay, I'll get to work on factoring out a (serializable) factory. Thanks 
for the discussion everyone! I think the parser types will be much stronger for 
it.


---

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



[GitHub] commons-rdf pull request #49: Cleanup for FindBugs and PMD warnings in -simp...

2018-02-14 Thread stain
Github user stain commented on a diff in the pull request:

https://github.com/apache/commons-rdf/pull/49#discussion_r168274256
  
--- Diff: 
commons-rdf-simple/src/main/java/org/apache/commons/rdf/simple/experimental/AbstractRDFParser.java
 ---
@@ -58,8 +60,12 @@
  */
 public abstract class AbstractRDFParser> 
implements RDFParser, Cloneable {
 
-public static final ThreadGroup threadGroup = new ThreadGroup("Commons 
RDF parsers");
-private static final ExecutorService threadpool = 
Executors.newCachedThreadPool(r -> new Thread(threadGroup, r));
+public static final AtomicInteger threadCount = new AtomicInteger();
+private static Thread newThread(Runnable r) {
--- End diff --

A final ThreadGroup that is not thread safe.. The whole purpose of it is to 
group threads?

It is true that they should not be used for security purpose, but that is 
not why it is here. The ThreadGroup is mainly useful for debugging as people 
might see these "Commons RDF Parser" tree grouped together in the debugger 
(e.g. in Eclipse) rather than the generic no-name you get from the 
ExecutorService.


---

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



[GitHub] commons-rdf pull request #43: COMMONSRDF-49: Make AbstractRDFParser serializ...

2018-02-14 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/commons-rdf/pull/43


---

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



[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable

2018-02-14 Thread ajs6f
Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
Hm... if @afs and @stain are both feeling reluctant to go this way... I 
would still be happy to merge it as-is and then work forward to the fluent-ish 
factory design (since @ansell has given a LGTM) and there is agreement that 
having fields not be `Optional`s is good in any case. @stain, would you like to 
see some checks against `null`-valued fields? I can certainly add those easily 
enough.


---

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



[GitHub] commons-rdf pull request #49: Cleanup for FindBugs and PMD warnings in -simp...

2018-02-14 Thread ajs6f
Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/commons-rdf/pull/49#discussion_r168260775
  
--- Diff: 
commons-rdf-simple/src/main/java/org/apache/commons/rdf/simple/experimental/AbstractRDFParser.java
 ---
@@ -58,8 +60,12 @@
  */
 public abstract class AbstractRDFParser> 
implements RDFParser, Cloneable {
 
-public static final ThreadGroup threadGroup = new ThreadGroup("Commons 
RDF parsers");
-private static final ExecutorService threadpool = 
Executors.newCachedThreadPool(r -> new Thread(threadGroup, r));
+public static final AtomicInteger threadCount = new AtomicInteger();
+private static Thread newThread(Runnable r) {
--- End diff --

Because either FindBugs or PMD (can't remember) which called out 
`ThreadGroup` as not threadsafe, which is correct as far as I know. I am in 
_no_ way wedded to this change and if we can guarantee thread-safety from 
outside the class (or simply document it as not threadsafe) I would be happy to 
pull this change out.


---

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



[All][RNG] FindBugs discontinued

2018-02-14 Thread Gilles

Hi.

FindBugs chokes on Java 9 "module-info" files[1] and the project has
been shut down. There is a replacement:
  https://spotbugs.github.io/
Is there some common configuration that could be included in CP?
Is someone intending to do it?

In the meantime, does someone know how to work around the build
failure caused by FindBugs raising an exception?  Error follows:
---CUT---
 [java] The following errors occurred during analysis:
 [java]   Invalid class resource module-info.class in 
/home/gilles/devel/java/apache/commons-rng/trunk/commons-rng-examples/examples-jpms/jpm

s-lib/target/classes:module-info.class
 [java] 
edu.umd.cs.findbugs.classfile.InvalidClassFileFormatException: Invalid 
classfile format in /home/gilles/devel/java/apache/commons

-rng/trunk/commons-rng-examples/examples-jpms/jpms-lib/target/classes:module-info.class
 [java]   At 
edu.umd.cs.findbugs.classfile.engine.ClassParser.readConstant(ClassParser.java:245)
 [java]   At 
edu.umd.cs.findbugs.classfile.engine.ClassParser.parse(ClassParser.java:102)
 [java]   At 
edu.umd.cs.findbugs.classfile.impl.ClassPathBuilder.parseClassName(ClassPathBuilder.java:716)
 [java]   At 
edu.umd.cs.findbugs.classfile.impl.ClassPathBuilder.scanCodebase(ClassPathBuilder.java:679)
 [java]   At 
edu.umd.cs.findbugs.classfile.impl.ClassPathBuilder.processWorkList(ClassPathBuilder.java:622)
 [java]   At 
edu.umd.cs.findbugs.classfile.impl.ClassPathBuilder.build(ClassPathBuilder.java:226)
 [java]   At 
edu.umd.cs.findbugs.FindBugs2.buildClassPath(FindBugs2.java:677)
 [java]   At 
edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:218)
 [java]   At 
edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:402)
 [java]   At 
edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1200)

 [java]   Error scanning module-info for referenced classes
 [java] java.lang.IllegalArgumentException
 [java]   At 
org.objectweb.asm.ClassReader.(ClassReader.java:170)
 [java]   At 
org.objectweb.asm.ClassReader.(ClassReader.java:153)
 [java]   At 
edu.umd.cs.findbugs.asm.FBClassReader.(FBClassReader.java:35)
 [java]   At 
edu.umd.cs.findbugs.classfile.engine.asm.ClassReaderAnalysisEngine.analyze(ClassReaderAnalysisEngine.java:48)
 [java]   At 
edu.umd.cs.findbugs.classfile.engine.asm.ClassReaderAnalysisEngine.analyze(ClassReaderAnalysisEngine.java:34)
 [java]   At 
edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:262)
 [java]   At 
edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:75)
 [java]   At 
edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
 [java]   At 
edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:262)
 [java]   At 
edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:774)
 [java]   At 
edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222)
 [java]   At 
edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:402)
 [java]   At 
edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1200)

---CUT---

Thanks,
Gilles

[1] Cf. https://github.com/gleclaire/findbugs-maven-plugin/issues/60

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



Re: commons-release-plugin git commit: Add self.

2018-02-14 Thread Gary Gregory
On Wed, Feb 14, 2018 at 8:04 AM, Rob Tompkins  wrote:

> Given the typographical errors, should we roll a 1.1?
>

Why not? :-) Meaning "Go for it" :-)

Gary


>
> > On Feb 14, 2018, at 9:45 AM, ggreg...@apache.org wrote:
> >
> > Repository: commons-release-plugin
> > Updated Branches:
> >  refs/heads/master efce48a13 -> 144b5ce3b
> >
> >
> > Add self.
> >
> > Project: http://git-wip-us.apache.org/repos/asf/commons-release-
> plugin/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/commons-release-
> plugin/commit/144b5ce3
> > Tree: http://git-wip-us.apache.org/repos/asf/commons-release-
> plugin/tree/144b5ce3
> > Diff: http://git-wip-us.apache.org/repos/asf/commons-release-
> plugin/diff/144b5ce3
> >
> > Branch: refs/heads/master
> > Commit: 144b5ce3bb36bed892666a5946bf5ba6fbcdbc9d
> > Parents: efce48a
> > Author: Gary Gregory 
> > Authored: Wed Feb 14 07:45:47 2018 -0700
> > Committer: Gary Gregory 
> > Committed: Wed Feb 14 07:45:47 2018 -0700
> >
> > --
> > pom.xml | 6 ++
> > 1 file changed, 6 insertions(+)
> > --
> >
> >
> > http://git-wip-us.apache.org/repos/asf/commons-release-
> plugin/blob/144b5ce3/pom.xml
> > --
> > diff --git a/pom.xml b/pom.xml
> > index 09432fb..ef35ed5 100644
> > --- a/pom.xml
> > +++ b/pom.xml
> > @@ -63,6 +63,12 @@
> > chtom...@apache.org
> > -5
> > 
> > +
> > +Gary Gregory
> > +ggregory
> > +ggreg...@apache.org
> > +-6
> > +
> > 
> >
> > 
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Apache EU Roadshow CFP Closing Soon (23 February)

2018-02-14 Thread Sharan F

Hello Everyone

This is an initial reminder to let you all know that we are holding an 
Apache EU Roadshow co-located with FOSS Backstage in Berlin on 13^th and 
14^th June 2018. https://s.apache.org/tCHx


The Call for Proposals (CFP) for the Apache EU Roadshow is currently 
open and will close at the end of next week, so if you have been 
delaying making a submission because the closing date seemed a long way 
off, then it's time to start getting your proposals submitted.


So what are we looking for?
We will have 2 Apache Devrooms available during the 2 day Roadshow so 
are looking for projects including incubating ones, to submit 
presentations, panel discussions, BoFs, or workshop proposals. The main 
focus of the Roadshow will be IoT, Cloud, Httpd and Tomcat so if your 
project is involved in or around any of these technologies at Apache 
then we are very interested in hearing from you.


Community and collaboration is important at Apache so if your project is 
interested in organising a project sprint, meetup or hackathon during 
the Roadshow, then please submit it inthe CFP as we do have some space 
available to allocate for these.


If you are wanting to submit a talk on open source community related 
topics such as the Apache Way, governance or legal aspects then please 
submit these to the CFP for FOSS Backstage.


Tickets for the Apache EU Roadshow are included as part of the 
registration for FOSS Backstage, so to attend the Roadshow you will need 
to register for FOSS Backstage. Early Bird tickets are still available 
until the 21^st February 2018.


Please see below for important URLs to remember:

-  To submit a CFP for the Apache EU Roadshow 
:http://apachecon.com/euroadshow18/ 


-  To submit a CFP for FOSS Backstage : 
https://foss-backstage.de/call-papers


-  To register to attend the Apache EU Roadshow and/or FOSS Backstage : 
https://foss-backstage.de/tickets


For further updates and information about the Apache EU Roadshowplease 
check http://apachecon.com/euroadshow18/


Thanks
Sharan Foga, VP Apache Community Development


Re: commons-release-plugin git commit: Add self.

2018-02-14 Thread Rob Tompkins
Given the typographical errors, should we roll a 1.1?

> On Feb 14, 2018, at 9:45 AM, ggreg...@apache.org wrote:
> 
> Repository: commons-release-plugin
> Updated Branches:
>  refs/heads/master efce48a13 -> 144b5ce3b
> 
> 
> Add self.
> 
> Project: http://git-wip-us.apache.org/repos/asf/commons-release-plugin/repo
> Commit: 
> http://git-wip-us.apache.org/repos/asf/commons-release-plugin/commit/144b5ce3
> Tree: 
> http://git-wip-us.apache.org/repos/asf/commons-release-plugin/tree/144b5ce3
> Diff: 
> http://git-wip-us.apache.org/repos/asf/commons-release-plugin/diff/144b5ce3
> 
> Branch: refs/heads/master
> Commit: 144b5ce3bb36bed892666a5946bf5ba6fbcdbc9d
> Parents: efce48a
> Author: Gary Gregory 
> Authored: Wed Feb 14 07:45:47 2018 -0700
> Committer: Gary Gregory 
> Committed: Wed Feb 14 07:45:47 2018 -0700
> 
> --
> pom.xml | 6 ++
> 1 file changed, 6 insertions(+)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/commons-release-plugin/blob/144b5ce3/pom.xml
> --
> diff --git a/pom.xml b/pom.xml
> index 09432fb..ef35ed5 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -63,6 +63,12 @@
> chtom...@apache.org
> -5
> 
> +
> +Gary Gregory
> +ggregory
> +ggreg...@apache.org
> +-6
> +
> 
> 
> 
> 


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

2018-02-14 Thread Gary Gregory
On Feb 14, 2018 03:05, "Jochen Wiedmann"  wrote:

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

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

As there seem to be other incompatible changes in the pipeline
(StrBuilder, etc.), this should be a good opportunity.


These changes are deprecations in favor of new code. Nothing will break BC.

Gary


Jochen

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

2018-02-14 Thread Jochen Wiedmann
On Tue, Feb 13, 2018 at 11:13 PM, Gary Gregory  wrote:

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

As there seem to be other incompatible changes in the pipeline
(StrBuilder, etc.), this should be a good opportunity.

Jochen

-
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

2018-02-14 Thread Claude Warren
@Charles,
I thought of Commons because it is where people go to find common code.  it
provides a web presence to base the code and discussion from.  Though
perhaps Github would suffice.

@Ralph,
I agree that reference implementations would be good.  But I didn't want to
start a "language war" with respect to what languages to support.  I think
that if there is a discussion and a consensus reached we are 90% of the way
to reference implementations.  What may be more critical are reference
tests.

I will come back to my discussion of Bloom filters because there is so much
variance in how they are implemented in the wild.  Bloom filters are used
in a number of products and (as far as I know) there is no place to go for
a clear, concise description of how to create them.  In fact the Cassandra
code has a comment block that indicates their modified code method is
faster and produces the same range of results as other methods.

Another algorithm that I can not find any detail on is the blockchain
mining algorithm.  How is a minor notifiied that a new block has been added
to the chain and who do they notify when they add a new block.  There are
lots of high level descriptions but no low level algorithm type info that I
have been able to find.

For algorithms like merge-sort or b-tree there are lots of books and other
publications that describe the algorithms, but many of the "newer"
constructs do not.  I see this project as a place developers can turn to to
find the information they need to implement various algorithms, and if not
to start a discussion about how to correctly implement it.

Claude







On Wed, Feb 14, 2018 at 3:33 AM, Charles Honton  wrote:

> 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 <
> e...@zusammenkunft.net>
> >>> 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