[LANG] Fixing LANG-1197 (Was: [ALL] JDK 9 Version String)

[Benedikt Ritter]

Hello Pascal,

can you please elaborate what problems you ran into? Your approach of
deprecating JAVA_1_9 looks promising to me.

Regards,
Benedikt

-- Forwarded message -
From: Pascal Schumacher 
Date: So., 11. Sep. 2016 um 20:13 Uhr
Subject: Re: [ALL] JDK 9 Version String
To: Commons Developers List 


I ran into that while taking a look at
https://issues.apache.org/jira/browse/LANG-1197

http://openjdk.java.net/jeps/223 specifies the new versioning string
schema, but I was not sure how add this to the current implementation
(without breaking anything).

Am 11.09.2016 um 18:31 schrieb Benedikt Ritter:
> Hello,
>
> I've created LANG-1264 [1] to address this for Commons Lang's JavaVersion
> enum.
>
> Regards,
> Benedikt
>
> [1] https://issues.apache.org/jira/browse/LANG-1264
>
> Gary Gregory  schrieb am Fr., 15. Juli 2016 um
> 17:34 Uhr:
>
>> Thank you for the pointers.
>>
>> Gary
>>
>> On Jul 15, 2016 4:02 AM, "dalibor topic" 
wrote:
>>
>>>
>>> On 14.07.2016 20:27, Gary Gregory wrote:
>>>
 Thank you, I subscribed and asked a question out of curiosity...

>>> Please see
>>> http://mail.openjdk.java.net/pipermail/verona-dev/2016-May/000409.html
>> in
>>> general and
>>>
>>
http://download.java.net/java/jdk9/docs/api/java/lang/Runtime.Version.html
>>> specifically.
>>>
>>> cheers,
>>> dalibor topic
>>>
>>> --
>>>  Dalibor Topic | Principal Product Manager
>>> Phone: +494089091214  | Mobile: +491737185961
>>> 
>>>
>>> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>>>
>>> ORACLE Deutschland B.V. & Co. KG
>>> Hauptverwaltung: Riesstr. 25, D-80992 München
>>> Registergericht: Amtsgericht München, HRA 95603
>>>
>>> Komplementärin: ORACLE Deutschland Verwaltung B.V.
>>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>>> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>>
>>>  Oracle is committed to developing
>>> practices and products that help protect the environment
>>>
>>> -
>>> 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

Jenkins build is back to stable : commons-beanutils » Apache Commons BeanUtils #5

[Apache Jenkins Server]

See 



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

Re: Another BeanUtils 1.9.3 RC?

[Gary Gregory]

On Mon, Sep 12, 2016 at 9:12 AM, Stian Soiland-Reyes 
wrote:

> Hi,
>
> Sorry about the time for fixing BEANUTILS-492 - a bit of dark magic to
> go through there inside
> the bean inspectors.
>
> https://issues.apache.org/jira/browse/BEANUTILS-492#
>
>
>
> Now that I think it's sorted for Java 6/7/8/9 - shall I have a go at
> creating a new Release Candidate for BeanUtils 1.9.3 ?
>

I think that was the only item holding us up.

Gary


>
>
> --
> Stian Soiland-Reyes
> 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
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[IO] SVN or GIt

[Gary Gregory]

Did we finish the conversion of commons-io from Svn to Git?

I cannot seem to push or pull from the git repo.

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Jenkins build is still unstable: commons-beanutils » Apache Commons BeanUtils #4

[Apache Jenkins Server]

See 



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

RE: [GitHub] commons-bcel pull request #10: BCEL-276 LocalVariableTypeTable is not update...

[Mark Roberts]

This issue needs to be reopened as the changes are incorrect.  I could not
figure out the magic to do so - but I did add comments and attached the
outline of a solution in the form of a diff file.

Thank you,
Mark Roberts

> -Original Message-
> From: asfgit [mailto:g...@git.apache.org]
> Sent: Monday, September 05, 2016 11:46 PM
> To: dev@commons.apache.org
> Subject: [GitHub] commons-bcel pull request #10: BCEL-276
> LocalVariableTypeTable is not update...
> 
> Github user asfgit closed the pull request at:
> 
> https://github.com/apache/commons-bcel/pull/10
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have
your reply
> appear on GitHub as well. If your project does not have this feature
enabled
> and wishes so, or if the feature is enabled but not working, please
contact
> infrastructure at infrastruct...@apache.org or file a JIRA ticket with
INFRA.
> ---
> 
> -
> 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

Jenkins build is back to stable : commons-beanutils #5

[Apache Jenkins Server]

See 


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

Another BeanUtils 1.9.3 RC?

[Stian Soiland-Reyes]

Hi,

Sorry about the time for fixing BEANUTILS-492 - a bit of dark magic to
go through there inside
the bean inspectors.

https://issues.apache.org/jira/browse/BEANUTILS-492#



Now that I think it's sorted for Java 6/7/8/9 - shall I have a go at
creating a new Release Candidate for BeanUtils 1.9.3 ?


-- 
Stian Soiland-Reyes
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

Jenkins build is still unstable: commons-beanutils #4

[Apache Jenkins Server]

See 


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

Re: [RDF] jena, rdf4j, json-ld integrations

[Peter Ansell]

Hi Stian,

Sesame-4 will not have any more releases due to the Eclipse migration,
so you will not have a large user-base for that. Even maintaining a
Sesame-2.8 module may not find many users, as users who are still
using it for the near future will likely not be migrating to Java-8
and hence won't be integrating Commons RDF as often as those who are
already migrating to Eclipse RDF4J.

Developing an integration for JSONLD-Java in the same way as I have
setup the others with their own repositories is a possibility for that
aspect, similar to:

https://github.com/jsonld-java/jsonld-java-clerezza

https://github.com/jsonld-java/jsonld-java-rdf2go

However, both Jena and Sesame/RDF4J have ended up having their
JSONLD-Java integrations moved back into their core repositories so it
isn't the same for everyone.

Cheers,

Peter

On 13 September 2016 at 09:55, Stian Soiland-Reyes  wrote:
> Hi,
>
> [[ Cross-posting - let's try to reply to dev@commons. ]]
>
>
> As you might have spotted if you've seen the Commons RDF Jira/commit
> emails, I have been working on adding integrations for Jena, RDF4j and
> JSONLD-Java on these branches:
>
>
> https://github.com/apache/incubator-commonsrdf/tree/jena
> https://github.com/apache/incubator-commonsrdf/tree/rdf4j
> https://github.com/apache/incubator-commonsrdf/tree/jsonld-java
>
>
> I think they are now nearing completion and so I would suggest we
> merge them to master to try to do a 0.3.0-incubating release of
> Commons RDF
>
>
> These include a full RDFTermfactory for each, includes Graph, Triple,
> Quad, Dataset and of course the various RDFTerms.
>
> The jena branch also includes support for generalized triples and
> generalized quads, implementing the freshly added TripleLike/QuadLike.
>
>
>
>
> See merged javadoc here:
>
> http://stain.github.io/incubator-commonsrdf/integration/
>
> e.g. under "All known implementing classes" at
>
> http://stain.github.io/incubator-commonsrdf/integration/org/apache/commons/rdf/api/RDFTermFactory.html
>
> http://stain.github.io/incubator-commonsrdf/integration/org/apache/commons/rdf/api/Triple.html
>
>
>
> Each implementation (except simple) work by wrapping their native classes, 
> e.g.
>
> https://github.com/apache/incubator-commonsrdf/blob/rdf4j/rdf4j/src/main/java/org/apache/commons/rdf/rdf4j/impl/TripleImpl.java
>
> .. which wraps a org.eclipse.rdf4j.model.Statement and constructs the
> RDFTerms of its subject/predicate/object on demand.
>
>
>
>
> I've also merged them all in a single branch to test if they are 
> interoperable:
>
> https://github.com/apache/incubator-commonsrdf/tree/jena-jsonld-rdf4j-integration/integration-tests
>
> The tests create RDFTerms/triples in one RDFTermFactory, then add them
> to a graph created with a 'foreign' RDFTermFactory, and then this is
> tested all-to-all between all factories, including retrieving back
> those previously difficult BlankNodes.
>
>
>
> Good news, everyone! They all talk to each other!
>
>
> And what surprised me most was that these three worked well enough
> without a classpath issues with any shared dependencies  - I thought
> it would be sensitive to say the JSON-LD Java or HTTPClient version -
> I guess more testing (in particular of parsing) would find out.
>
>
>
>
>
>
> I also used sed to make a  search-replace variant of rdf4j for older
> sesame 4 as the big differences are just package names import from
> org.openrdf instead of org.eclipse.rdf4j.
>
> https://github.com/stain/incubator-commonsrdf/tree/sesame4
>
> (I didn't commit this to Apache as I'm not sure if we would want to
> support such a 'clone' of the rdf4j module, it would require double
> maintenance -- but in theory this could be used for interoperability
> between sesame4 and rdf4j! :)
>
>
>
> Now is the time to discuss some strategy points!
>
> I'll ask about those in separate emails, and I'll copy
> dev@commons.apache.org as I think we can have good feedback there also
> from non-RDF folks - e.g. as we need to agree on common styles etc.
>
> (And we need to practice moving our Commons RDF email traffic to dev@commons)
>
>
> --
> Stian Soiland-Reyes
> 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
>

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

Re: [RDF] adaptation methods in RDFTermFactory?

[Matt Sicker]

Couldn't you do the JDBC Wrapper style interface and have a generic method
like:

 T unwrap(Class cls);

Or make more specific unwrap methods like:

 T unwrap(Class cls);

If this is for implementation-specific casts and such.

On 12 September 2016 at 19:56, Stian Soiland-Reyes  wrote:

> [[ Cross-post - prefer replies to dev@commons ]]
>
> Each of the Common RDF implementations come with a RDFTermFatory
>
> http://stain.github.io/incubator-commonsrdf/integration/org/apache/
> commons/rdf/api/RDFTermFactory.html
>
> On a classical flat classloader the implementations of this factory
> can be discovered with java.util.ServiceLoader
>
>
> So if you have say a JsonLdRDFTermFactory you can call .createTriple()
> etc - and it would be backed by that implementation. As mentioned the
> marker interfaces will allow you to later on get hold of the wrapped
> object, e.g. to do some RDFS reasoning on a Jena Model or to parse it
> to a serializer.
>
>
> But what if you already have a 'native' object, e.g. a
> org.eclipse.rdf4j.model.Statement - and you want to convert it/adapt
> it to the corresponding Commons RDF API Triple?
>
> Obviously there would not be a general interface for this (without
> using ?-generics) as each backend implementation would have different
> (so far unrelated) types - but we can at least agree on the common
> style?
>
> In
>
> http://stain.github.io/incubator-commonsrdf/integration/org/apache/
> commons/rdf/rdf4j/RDF4JTermFactory.html
>
> I suggests as*() adapter methods like:
>
>
> RDF4JQuad asQuad(org.eclipse.rdf4j.model.Statement
>
> RDF4JTriple asTriple(org.eclipse.rdf4j.model.Statement statement)
>
> RDF4JTerm asRDFTerm(org.eclipse.rdf4j.model.Value value)
>
> RDF4JDataset asRDFTermDataset(org.eclipse.rdf4j.repository.Repository
> repository)
>
> RDF4JGraph  asRDFTermGraph(org.eclipse.rdf4j.model.Model model)
>
> RDF4JGraph  asRDFTermGraph(org.eclipse.rdf4j.repository.Repository
> repository)
>
>
> but also the inverse converters:
>
> org.eclipse.rdf4j.model.Value  asValue(RDFTerm term)
>
> org.eclipse.rdf4j.model.Statement
> asStatement(TripleLike tripleLike)
>
>
> (These will unpack the wrapped value if it's an RDF4JTerm - or create
> a new RDF4J native instance if it's a "foreign" class)
>
>
> Questions:
>
>
> a) Do these adapter methods belong in the RDFTermFactory or should
> there be a new family of 'adaptor factories'? (e.g. the Jena Factory
>
>
> b) What should we call these methods?  Is as*() appropriate or should
> they more closely match the createTriple() etc methods from
> RDFTermFactory?
>
> With asSomething() I wanted to hint of adaptation - rather than
> 'convert' or 'create' - but without having to commit to adaptation
> with adapt() or wrap().
>
>
> Now sometimes the implementations use the same class name as Commons
> RDF (e.g. Quad or Graph). Code-wise this is not too hard to deal with
> (avoid importing either), but it means it can get more confusing for
> downstream API users who do auto-complete and then don't know what
> direction they are adapting.
>
>
> c) Should the adapter methods have short names (e.g. asGraph()) -
> distinguished by type polymorphism and javadocs - or more verbose to
> show which particular return-type you get? (e.g. asJenaGraph() and
> asCommonsRDFGraph()) )
>
>
> d) Do we need to rename RDFTermFactory to RDFFactory (or just RDF) ?
>
>
>
> --
> Stian Soiland-Reyes
> 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
>
>


-- 
Matt Sicker 

Re: Apache Commons Report Due

[Gilles]

On Mon, 12 Sep 2016 12:51:30 -0700, Gary Gregory wrote:

Here is what I plan to send:



?
[Or an empty report.]

Gilles

On Sun, Sep 11, 2016 at 11:43 AM, Matt Sicker  
wrote:



That sounds like it sums it up to date.

On 11 September 2016 at 10:45, Gary Gregory 
wrote:

> Is there anything specific you'd like noted WRT Commons Math and 
Commons

> RNG?
>
> Otherwise I'll keep it simple: The Commons community has decided 
to bring

> forth and maintain a new component, Commons RNG, out of the larger
Commons
> Math code base, which is has seen no activity in the last quarter. 
The
> future of Commons Math is still uncertain and being discussed from 
time

to
> time.
>
> Gary
>
> On Sat, Sep 10, 2016 at 11:40 AM, Matt Sicker  
wrote:

>
> > * The commons math evolution.
> > * Commons crypto 1.0
> >
> > I don't think anything else too exciting has happened other than 
normal

> > releases.
> >
> > On 10 September 2016 at 13:21, Gary Gregory 


> > wrote:
> >
> > > I will send out our quarterly report later today or tomorrow.
> > >
> > > Is there anything you'd like to see mentioned?
> > >
> > > Gary
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > Java Persistence with Hibernate, Second Edition
> > > 
> > > JUnit in Action, Second Edition 


> > > Spring Batch in Action 
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
> >
> >
> > --
> > Matt Sicker 
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



--
Matt Sicker 




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

Re: [RDF] Implementation class name style?

[Gary Gregory]

Hi,

For names, I like CamelCaseEvenForAcronyms, like IbmXmlSaxParser instead of
IBMXMLSAXParser.

Gary

On Mon, Sep 12, 2016 at 5:32 PM, Stian Soiland-Reyes 
wrote:

> [[ I've copied both lists, prefer replies to dev@commons.apache.org ]]
>
> What style should we use for packages and class names for the Commons
> RDF Term implementations?
>
>
> To give an example:
>
> http://stain.github.io/incubator-commonsrdf/integration/org/apache/
> commons/rdf/api/IRI.html
>
> (org.apache.commons.rdf.api.* is pretty-much locked down and agreed by
> the incubator project - but I'm thinking of what to call the
> implementations here now)
>
>
> That is the Commons RDF API interface:
>
> org.apache.commons.rdf.api.IRI
>
>
> is extended by "marker" interfaces per implementation:
>
> org.apache.commons.rdf.jena.JenaIRI
> org.apache.commons.rdf.jsonldjava.JsonLdIRI
> org.apache.commons.rdf.rdf4j.RDF4JIRI
>
> (adds methods like asJenaNode() to reveal the underlying 'native'
> implementations)
>
>
> and the corresponding implementations which actually wrap the
> underlying library's classes:
>
> org.apache.commons.rdf.simple.IRIImpl
> org.apache.commons.rdf.jena.impl.IRIImpl
> org.apache.commons.rdf.rdf4j.impl.IRIImpl
> org.apache.commons.rdf.jsonldjava.JsonLdIRI.JsonLdIRIImpl
>
>
>
>
> for Graph there are quite a few more implementations:
>
> org.apache.commons.rdf.simple.GraphImpl
> org.apache.commons.rdf.simple.DatasetGraphView
> org.apache.commons.rdf.jsonldjava.JsonLdGraph
> org.apache.commons.rdf.jsonldjava.JsonLdUnionGraph
> org.apache.commons.rdf.rdf4j.impl.ModelGraphImpl
> org.apache.commons.rdf.rdf4j.impl.RepositoryGraphImpl
> org.apache.commons.rdf.jena.impl.GraphImpl
>
>
> but I only made marker interfaces:
>
> org.apache.commons.rdf.jena.JenaGraph
> org.apache.commons.rdf.rdf4j.RDF4JGraph
>
>
>
> Questions:
>
> a) Should we keep the marker interfaces for RDFTerms (e.g.
> jena.JenaIRI) or just have the implementations directly (e.g. as in
> simple.IRIImpl)
>
> a2)  Should simple also have a marker interface?  (..they don't have
> anything 'inner' to expose)
>
>
> b) Should we have marker interfaces for the Graph/Dataset
> implementations? Here getting access to the underlying model is
> probably more important.
>
>
> c) What style for the implementation class name? E.g. should they all
> have the same name like "IRIImpl" (perhaps confusing if you have more
> than one module on classpath), or better with prefix, e.g.
> "JsonLdIRIImpl"?
>
> d) Where should the implementation live?  sub-package like
> org.apache.commons.rdf.jena.impl, or same package as marker interfaces
>  -- or as inner class of the marker interface?
>
> (I know - the last sounds nasty - but it's actually quite tidy if we
> decide to not make the implementation package-protected, particularly
> as most of these marker interfaces are pretty empty :
>
> https://github.com/apache/incubator-commonsrdf/blob/
> jsonld-java/jsonld-java/src/main/java/org/apache/commons/
> rdf/jsonldjava/JsonLdQuad.java
> )
>
>
> e)  How visible should the implementations be, package or public classes?
>
> f) package or public constructors?  They should mostly be possible to
> create through the corresponding RDFTermFactory - and 'package' would
> mean we could update it in a minor or patch version.
>
> g) - if implementation classes are public - should the implementations
> be marked 'final'?
>
> h) how do we construct a package-protected class from the factory
> (which is not in .impl)? Jena adds a impl.JenaFactory for this purpose
> - but it seems to duplicate most of JenaRDFTermFactory.
>
> https://github.com/apache/incubator-commonsrdf/blob/
> jena/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaFactory.java
> https://github.com/apache/incubator-commonsrdf/blob/
> jena/jena/src/main/java/org/apache/commons/rdf/jena/
> JenaRDFTermFactory.java
>
>
>
>
> Thanks for any suggestions!
>
>
>
> --
> Stian Soiland-Reyes
> 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
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Apache Commons Report Due

[Gary Gregory]

Oops, here it is:

## Description:

The Apache Commons project focuses on all aspects of reusable Java
components.

The Apache Commons components are widely used in many projects, both within
Apache and without. Any ASF committer can commit to Apache Commons.

The last report was on June 7 2016.

## Issues:
 - There are no issues that requires the boards attention this quarter.

## Activity:
 - The project is active with 4 releases this reporting period. One new
 component being is being readied for release (Commons RNG) and another
 component is still in limbo (Commons Math.) after having been forked.
 Commons RDF is slowly making its way through the incubator.

 - The Commons community has decided to bring forth and maintain a new
 component, Commons RNG, out of the larger Commons Math code base, which is
 has seen no activity in the last quarter. The future of Commons Math is
 still uncertain and being discussed from time to time.

## Health report:
 - Most components in Commons are mature, but are still actively
 maintained (4 releases). The dev list is active. JIRA is active. Speed of
 responses to users is reasonable in most cases. We have 4 new committers,
 and Commons is still open to any Apache Committer.

## PMC changes:

 - Currently 35 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Stian Soiland-Reyes on Wed May 18 2016

## Committer base changes:

 - Currently 142 committers.
 - New commmitters:
- Artem Barger was added as a committer on Sun Aug 14 2016
- Rob Tompkins was added as a committer on Mon Aug 22 2016
- Eric Barnhill was added as a committer on Tue Sep 06 2016
- Matt Sicker was added as a committer on Wed Jul 27 2016

## Releases:

 - BCEL-6.0 was released on Wed Jul 13 2016
 - COMPRESS 1.12 was released on Mon Jun 20 2016
 - CONFIGURATION-2.1 was released on Fri Aug 19 2016
 - CRYPTO-1.0.0 was released on Mon Aug 08 2016

## Mailing list activity:

 - The stats below show no significant change since last quarter.
 The dev list is active. Speed of responses to users is reasonable
 in most cases.

 - dev@commons.apache.org:
- 680 subscribers (down -7 in the last 3 months):
- 1609 emails sent to list (1714 in previous quarter)

 - iss...@commons.apache.org:
- 301 subscribers (down -1 in the last 3 months):
- 1682 emails sent to list (2339 in previous quarter)

 - notificati...@commons.apache.org:
- 12 subscribers (up 0 in the last 3 months):
- 247 emails sent to list (281 in previous quarter)

 - u...@commons.apache.org:
- 1236 subscribers (up 8 in the last 3 months):
- 83 emails sent to list (166 in previous quarter)


## JIRA activity:

 - 209 JIRA tickets created in the last 3 months
 - 178 JIRA tickets closed/resolved in the last 3 months

On Mon, Sep 12, 2016 at 5:53 PM, Gilles 
wrote:

> On Mon, 12 Sep 2016 12:51:30 -0700, Gary Gregory wrote:
>
>> Here is what I plan to send:
>>
>>
> ?
> [Or an empty report.]
>
> Gilles
>
>
> On Sun, Sep 11, 2016 at 11:43 AM, Matt Sicker  wrote:
>>
>> That sounds like it sums it up to date.
>>>
>>> On 11 September 2016 at 10:45, Gary Gregory 
>>> wrote:
>>>
>>> > Is there anything specific you'd like noted WRT Commons Math and
>>> Commons
>>> > RNG?
>>> >
>>> > Otherwise I'll keep it simple: The Commons community has decided to
>>> bring
>>> > forth and maintain a new component, Commons RNG, out of the larger
>>> Commons
>>> > Math code base, which is has seen no activity in the last quarter. The
>>> > future of Commons Math is still uncertain and being discussed from time
>>> to
>>> > time.
>>> >
>>> > Gary
>>> >
>>> > On Sat, Sep 10, 2016 at 11:40 AM, Matt Sicker 
>>> wrote:
>>> >
>>> > > * The commons math evolution.
>>> > > * Commons crypto 1.0
>>> > >
>>> > > I don't think anything else too exciting has happened other than
>>> normal
>>> > > releases.
>>> > >
>>> > > On 10 September 2016 at 13:21, Gary Gregory 
>>> > > wrote:
>>> > >
>>> > > > I will send out our quarterly report later today or tomorrow.
>>> > > >
>>> > > > Is there anything you'd like to see mentioned?
>>> > > >
>>> > > > Gary
>>> > > >
>>> > > > --
>>> > > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> > > > Java Persistence with Hibernate, Second Edition
>>> > > > 
>>> > > > JUnit in Action, Second Edition 
>>> > > > Spring Batch in Action 
>>> > > > Blog: http://garygregory.wordpress.com
>>> > > > Home: http://garygregory.com/
>>> > > > Tweet! http://twitter.com/GaryGregory
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Matt Sicker 
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> > Java Persistence with Hibernate, Second Edition
>>> > 
>>> > JUnit in Action, 

Re: Apache Commons Report Due

[Gary Gregory]

Here is what I plan to send:


On Sun, Sep 11, 2016 at 11:43 AM, Matt Sicker  wrote:

> That sounds like it sums it up to date.
>
> On 11 September 2016 at 10:45, Gary Gregory 
> wrote:
>
> > Is there anything specific you'd like noted WRT Commons Math and Commons
> > RNG?
> >
> > Otherwise I'll keep it simple: The Commons community has decided to bring
> > forth and maintain a new component, Commons RNG, out of the larger
> Commons
> > Math code base, which is has seen no activity in the last quarter. The
> > future of Commons Math is still uncertain and being discussed from time
> to
> > time.
> >
> > Gary
> >
> > On Sat, Sep 10, 2016 at 11:40 AM, Matt Sicker  wrote:
> >
> > > * The commons math evolution.
> > > * Commons crypto 1.0
> > >
> > > I don't think anything else too exciting has happened other than normal
> > > releases.
> > >
> > > On 10 September 2016 at 13:21, Gary Gregory 
> > > wrote:
> > >
> > > > I will send out our quarterly report later today or tomorrow.
> > > >
> > > > Is there anything you'd like to see mentioned?
> > > >
> > > > Gary
> > > >
> > > > --
> > > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > > Java Persistence with Hibernate, Second Edition
> > > > 
> > > > JUnit in Action, Second Edition 
> > > > Spring Batch in Action 
> > > > Blog: http://garygregory.wordpress.com
> > > > Home: http://garygregory.com/
> > > > Tweet! http://twitter.com/GaryGregory
> > > >
> > >
> > >
> > >
> > > --
> > > Matt Sicker 
> > >
> >
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> > 
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
>
>
> --
> Matt Sicker 
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[RDF] adaptation methods in RDFTermFactory?

[Stian Soiland-Reyes]

[[ Cross-post - prefer replies to dev@commons ]]

Each of the Common RDF implementations come with a RDFTermFatory

http://stain.github.io/incubator-commonsrdf/integration/org/apache/commons/rdf/api/RDFTermFactory.html

On a classical flat classloader the implementations of this factory
can be discovered with java.util.ServiceLoader


So if you have say a JsonLdRDFTermFactory you can call .createTriple()
etc - and it would be backed by that implementation. As mentioned the
marker interfaces will allow you to later on get hold of the wrapped
object, e.g. to do some RDFS reasoning on a Jena Model or to parse it
to a serializer.


But what if you already have a 'native' object, e.g. a
org.eclipse.rdf4j.model.Statement - and you want to convert it/adapt
it to the corresponding Commons RDF API Triple?

Obviously there would not be a general interface for this (without
using ?-generics) as each backend implementation would have different
(so far unrelated) types - but we can at least agree on the common
style?

In

http://stain.github.io/incubator-commonsrdf/integration/org/apache/commons/rdf/rdf4j/RDF4JTermFactory.html

I suggests as*() adapter methods like:


RDF4JQuad asQuad(org.eclipse.rdf4j.model.Statement

RDF4JTriple asTriple(org.eclipse.rdf4j.model.Statement statement)

RDF4JTerm asRDFTerm(org.eclipse.rdf4j.model.Value value)

RDF4JDataset asRDFTermDataset(org.eclipse.rdf4j.repository.Repository
repository)

RDF4JGraph  asRDFTermGraph(org.eclipse.rdf4j.model.Model model)

RDF4JGraph  asRDFTermGraph(org.eclipse.rdf4j.repository.Repository repository)


but also the inverse converters:

org.eclipse.rdf4j.model.Value  asValue(RDFTerm term)

org.eclipse.rdf4j.model.Statement
asStatement(TripleLike tripleLike)


(These will unpack the wrapped value if it's an RDF4JTerm - or create
a new RDF4J native instance if it's a "foreign" class)


Questions:


a) Do these adapter methods belong in the RDFTermFactory or should
there be a new family of 'adaptor factories'? (e.g. the Jena Factory


b) What should we call these methods?  Is as*() appropriate or should
they more closely match the createTriple() etc methods from
RDFTermFactory?

With asSomething() I wanted to hint of adaptation - rather than
'convert' or 'create' - but without having to commit to adaptation
with adapt() or wrap().


Now sometimes the implementations use the same class name as Commons
RDF (e.g. Quad or Graph). Code-wise this is not too hard to deal with
(avoid importing either), but it means it can get more confusing for
downstream API users who do auto-complete and then don't know what
direction they are adapting.


c) Should the adapter methods have short names (e.g. asGraph()) -
distinguished by type polymorphism and javadocs - or more verbose to
show which particular return-type you get? (e.g. asJenaGraph() and
asCommonsRDFGraph()) )


d) Do we need to rename RDFTermFactory to RDFFactory (or just RDF) ?



-- 
Stian Soiland-Reyes
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: Could you please checkout this PR?

[Jiju Kuruvilla]

Thank you, Matt!

jiju

On Mon, Sep 12, 2016 at 6:15 PM, Matt Sicker  wrote:

> PR = pull request. It's how people contribute patches via GitHub.
>
> On 12 September 2016 at 17:04, Jiju Kuruvilla 
> wrote:
>
> > hello,
> >
> > I am totally new to this. I know this may sound stupid, but what is a
> PR? I
> > joined this project to learn as well as with the intention of helping
> out.
> >
> > thanks,
> >
> > jiju
> >
> > On Sun, Sep 11, 2016 at 4:31 AM, Behrang Saeedzadeh  >
> > wrote:
> >
> > > Hi fellows,
> > >
> > > I've addressed all the comments regarding this PR:
> > > https://github.com/apache/commons-io/pull/17
> > >
> > > Could you please kindly merge it or let me know if there's anything
> else
> > > remaining that I should address before it can be merged?
> > > --
> > > Best regards,
> > > Behrang Saeedzadeh
> > >
> >
>
>
>
> --
> Matt Sicker 
>

[RDF] jena, rdf4j, json-ld integrations

[Stian Soiland-Reyes]

Hi,

[[ Cross-posting - let's try to reply to dev@commons. ]]


As you might have spotted if you've seen the Commons RDF Jira/commit
emails, I have been working on adding integrations for Jena, RDF4j and
JSONLD-Java on these branches:


https://github.com/apache/incubator-commonsrdf/tree/jena
https://github.com/apache/incubator-commonsrdf/tree/rdf4j
https://github.com/apache/incubator-commonsrdf/tree/jsonld-java


I think they are now nearing completion and so I would suggest we
merge them to master to try to do a 0.3.0-incubating release of
Commons RDF


These include a full RDFTermfactory for each, includes Graph, Triple,
Quad, Dataset and of course the various RDFTerms.

The jena branch also includes support for generalized triples and
generalized quads, implementing the freshly added TripleLike/QuadLike.




See merged javadoc here:

http://stain.github.io/incubator-commonsrdf/integration/

e.g. under "All known implementing classes" at

http://stain.github.io/incubator-commonsrdf/integration/org/apache/commons/rdf/api/RDFTermFactory.html

http://stain.github.io/incubator-commonsrdf/integration/org/apache/commons/rdf/api/Triple.html



Each implementation (except simple) work by wrapping their native classes, e.g.

https://github.com/apache/incubator-commonsrdf/blob/rdf4j/rdf4j/src/main/java/org/apache/commons/rdf/rdf4j/impl/TripleImpl.java

.. which wraps a org.eclipse.rdf4j.model.Statement and constructs the
RDFTerms of its subject/predicate/object on demand.




I've also merged them all in a single branch to test if they are interoperable:

https://github.com/apache/incubator-commonsrdf/tree/jena-jsonld-rdf4j-integration/integration-tests

The tests create RDFTerms/triples in one RDFTermFactory, then add them
to a graph created with a 'foreign' RDFTermFactory, and then this is
tested all-to-all between all factories, including retrieving back
those previously difficult BlankNodes.



Good news, everyone! They all talk to each other!


And what surprised me most was that these three worked well enough
without a classpath issues with any shared dependencies  - I thought
it would be sensitive to say the JSON-LD Java or HTTPClient version -
I guess more testing (in particular of parsing) would find out.






I also used sed to make a  search-replace variant of rdf4j for older
sesame 4 as the big differences are just package names import from
org.openrdf instead of org.eclipse.rdf4j.

https://github.com/stain/incubator-commonsrdf/tree/sesame4

(I didn't commit this to Apache as I'm not sure if we would want to
support such a 'clone' of the rdf4j module, it would require double
maintenance -- but in theory this could be used for interoperability
between sesame4 and rdf4j! :)



Now is the time to discuss some strategy points!

I'll ask about those in separate emails, and I'll copy
dev@commons.apache.org as I think we can have good feedback there also
from non-RDF folks - e.g. as we need to agree on common styles etc.

(And we need to practice moving our Commons RDF email traffic to dev@commons)


-- 
Stian Soiland-Reyes
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: Could you please checkout this PR?

[Jiju Kuruvilla]

hello,

I am totally new to this. I know this may sound stupid, but what is a PR? I
joined this project to learn as well as with the intention of helping out.

thanks,

jiju

On Sun, Sep 11, 2016 at 4:31 AM, Behrang Saeedzadeh 
wrote:

> Hi fellows,
>
> I've addressed all the comments regarding this PR:
> https://github.com/apache/commons-io/pull/17
>
> Could you please kindly merge it or let me know if there's anything else
> remaining that I should address before it can be merged?
> --
> Best regards,
> Behrang Saeedzadeh
>

Re: Could you please checkout this PR?

[Matt Sicker]

PR = pull request. It's how people contribute patches via GitHub.

On 12 September 2016 at 17:04, Jiju Kuruvilla  wrote:

> hello,
>
> I am totally new to this. I know this may sound stupid, but what is a PR? I
> joined this project to learn as well as with the intention of helping out.
>
> thanks,
>
> jiju
>
> On Sun, Sep 11, 2016 at 4:31 AM, Behrang Saeedzadeh 
> wrote:
>
> > Hi fellows,
> >
> > I've addressed all the comments regarding this PR:
> > https://github.com/apache/commons-io/pull/17
> >
> > Could you please kindly merge it or let me know if there's anything else
> > remaining that I should address before it can be merged?
> > --
> > Best regards,
> > Behrang Saeedzadeh
> >
>



-- 
Matt Sicker 

[RDF] Implementation class name style?

[Stian Soiland-Reyes]

[[ I've copied both lists, prefer replies to dev@commons.apache.org ]]

What style should we use for packages and class names for the Commons
RDF Term implementations?


To give an example:

http://stain.github.io/incubator-commonsrdf/integration/org/apache/commons/rdf/api/IRI.html

(org.apache.commons.rdf.api.* is pretty-much locked down and agreed by
the incubator project - but I'm thinking of what to call the
implementations here now)


That is the Commons RDF API interface:

org.apache.commons.rdf.api.IRI


is extended by "marker" interfaces per implementation:

org.apache.commons.rdf.jena.JenaIRI
org.apache.commons.rdf.jsonldjava.JsonLdIRI
org.apache.commons.rdf.rdf4j.RDF4JIRI

(adds methods like asJenaNode() to reveal the underlying 'native'
implementations)


and the corresponding implementations which actually wrap the
underlying library's classes:

org.apache.commons.rdf.simple.IRIImpl
org.apache.commons.rdf.jena.impl.IRIImpl
org.apache.commons.rdf.rdf4j.impl.IRIImpl
org.apache.commons.rdf.jsonldjava.JsonLdIRI.JsonLdIRIImpl




for Graph there are quite a few more implementations:

org.apache.commons.rdf.simple.GraphImpl
org.apache.commons.rdf.simple.DatasetGraphView
org.apache.commons.rdf.jsonldjava.JsonLdGraph
org.apache.commons.rdf.jsonldjava.JsonLdUnionGraph
org.apache.commons.rdf.rdf4j.impl.ModelGraphImpl
org.apache.commons.rdf.rdf4j.impl.RepositoryGraphImpl
org.apache.commons.rdf.jena.impl.GraphImpl


but I only made marker interfaces:

org.apache.commons.rdf.jena.JenaGraph
org.apache.commons.rdf.rdf4j.RDF4JGraph



Questions:

a) Should we keep the marker interfaces for RDFTerms (e.g.
jena.JenaIRI) or just have the implementations directly (e.g. as in
simple.IRIImpl)

a2)  Should simple also have a marker interface?  (..they don't have
anything 'inner' to expose)


b) Should we have marker interfaces for the Graph/Dataset
implementations? Here getting access to the underlying model is
probably more important.


c) What style for the implementation class name? E.g. should they all
have the same name like "IRIImpl" (perhaps confusing if you have more
than one module on classpath), or better with prefix, e.g.
"JsonLdIRIImpl"?

d) Where should the implementation live?  sub-package like
org.apache.commons.rdf.jena.impl, or same package as marker interfaces
 -- or as inner class of the marker interface?

(I know - the last sounds nasty - but it's actually quite tidy if we
decide to not make the implementation package-protected, particularly
as most of these marker interfaces are pretty empty :

https://github.com/apache/incubator-commonsrdf/blob/jsonld-java/jsonld-java/src/main/java/org/apache/commons/rdf/jsonldjava/JsonLdQuad.java
)


e)  How visible should the implementations be, package or public classes?

f) package or public constructors?  They should mostly be possible to
create through the corresponding RDFTermFactory - and 'package' would
mean we could update it in a minor or patch version.

g) - if implementation classes are public - should the implementations
be marked 'final'?

h) how do we construct a package-protected class from the factory
(which is not in .impl)? Jena adds a impl.JenaFactory for this purpose
- but it seems to duplicate most of JenaRDFTermFactory.

https://github.com/apache/incubator-commonsrdf/blob/jena/jena/src/main/java/org/apache/commons/rdf/jena/impl/JenaFactory.java
https://github.com/apache/incubator-commonsrdf/blob/jena/jena/src/main/java/org/apache/commons/rdf/jena/JenaRDFTermFactory.java




Thanks for any suggestions!



-- 
Stian Soiland-Reyes
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

Jenkins build became unstable: commons-beanutils #3

[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 became unstable: commons-beanutils » Apache Commons BeanUtils #3

[Apache Jenkins Server]

See 



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