Re: [PROPOSAL] Apache Commons JUnit

+1 for the idea and for looking at JUnit 5.x and maybe AssertJ. CheersBruno From: Matt Sicker To: Commons Developers List Sent: Saturday, 4 November 2017 1:44 PM Subject: Re: [PROPOSAL] Apache Commons JUnit I certainly like the idea,

Re: [PROPOSAL] Apache Commons JUnit

I certainly like the idea, especially if the docs are good about pulling in other related dependencies to complement the whole thing. General resource management rules would be great, though, like the ones we have in Log4j. Also, I haven't looked closely at it yet, but supporting JUnit 5.x as

[GitHub] commons-rdf issue #44: COMMONSRDF-70: Upgrade Jena version to 3.5.0

Github user acoburn commented on the issue: https://github.com/apache/commons-rdf/pull/44 In fact, I can confirm that commons-rdf-jena/0.5.0 works fine with jena/3.5.0 --- - To unsubscribe, e-mail:

[GitHub] commons-rdf issue #44: COMMONSRDF-70: Upgrade Jena version to 3.5.0

Github user ajs6f commented on the issue: https://github.com/apache/commons-rdf/pull/44 Definitely can wait. There's no substantive API changes at stake, and anyone who wants to use Jena 3.5.0 w/ Commons RDF should be able to override the transitive dependency without untoward

Re: [PROPOSAL] Apache Commons JUnit

Sounds like a logical category of reusable components. I'm a lurker but I think that is a very very cool idea! On Nov 3, 2017 4:11 PM, "Gary Gregory" wrote: > Hi All, > > I'd propose we start a new component called "Apache Commons JUnit". > > The goal would be to gather

Re: [lang] release 3.7

Done! Gary On Nov 3, 2017 12:04, "Stephen Colebourne" wrote: > You'd need https://github.com/apache/commons-lang/pull/304 too for Java 9 > > Stephen > > On 3 November 2017 at 17:36, Gary Gregory wrote: > > Hi All: > > > > I propose we release 3.7

[PROPOSAL] Apache Commons JUnit

Hi All, I'd propose we start a new component called "Apache Commons JUnit". The goal would be to gather useful and reusable code like JUnit rules. This component would be focused on JUnit 4.x only. For example: org.apache.commons.collections4.junit.SetDefaultLocaleTestRule I have other rules

Re: [lang] release 3.7

You'd need https://github.com/apache/commons-lang/pull/304 too for Java 9 Stephen On 3 November 2017 at 17:36, Gary Gregory wrote: > Hi All: > > I propose we release 3.7 principally to pick up > https://issues.apache.org/jira/browse/LANG-1365 to support those brave >

[lang] release 3.7

Hi All: I propose we release 3.7 principally to pick up https://issues.apache.org/jira/browse/LANG-1365 to support those brave souls trying out Java 10 EA. Gary

[GitHub] commons-rdf pull request #44: COMMONSRDF-70: Upgrade Jena version to 3.5.0

GitHub user ajs6f opened a pull request: https://github.com/apache/commons-rdf/pull/44 COMMONSRDF-70: Upgrade Jena version to 3.5.0 You can merge this pull request into a Git repository by running: $ git pull https://github.com/ajs6f/commons-rdf COMMONSRDF-70 Alternatively

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

Github user ajs6f commented on the issue: https://github.com/apache/commons-rdf/pull/43 Well, it's hard for me to say, because I'm trying to predict the architecture of a system I am only beginning to design. :( @afs, @sebbASF, how about I break out a separate type for

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

Github user afs commented on the issue: https://github.com/apache/commons-rdf/pull/43 AbstractRDFParser is stateful at some points in its lifecycle - input stream and the threadpool/futures. Is this mixing a builder for the configuration, where serialization makes sense,

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

Github user ajs6f commented on the issue: https://github.com/apache/commons-rdf/pull/43 From my POV, serializing a parser is useful for very long or very large ETL when you may need to either pause and resume parsing (persisting the state of the task in between) or move parsing tasks

JDK 10 b29 Early Access is available on jdk.java.net

Hi Benedikt, JDK 10 Early Access  build 29 is available at : - jdk.java.net/10/ JDK 10 Early Access Release Notes are available [1] JDK 10 Schedule, Status & Features are available [2] Notes * OpenJDK EA binaries will be available at a later date. * Oracle has proposed: Newer

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

Github user afs commented on the issue: https://github.com/apache/commons-rdf/pull/43 Relaying a question from sebb on the JIRA: https://issues.apache.org/jira/browse/COMMONSRDF-49#comment-16236065 including pointing out the long term restriction that comes with it. ---

Re: Tagging Daemon 1.1

On 11/02/2017 03:42 PM, Mark Thomas wrote: > I'm happy to go with the majority preference (mine being for 1.1.0). I'm more concerned about consistency between releases than the actual version format. commons-daemon has always used 3 digits, so 1.1.0 is fine. But releasing lang 3.7.0 after 3.6