On 15 Sep 2016 5:11 a.m., "Peter Ansell" <ansell.pe...@gmail.com> wrote:
> One of the original goals was to help with migration and
> interoperability so if it doesn't then things would need to be
> reworked on the Commons RDF side to support that.
I would hope it does that now :-)
> The main dependencies that are shared and liable to break are the
> FasterXML Jackson and Apache HttpClient dependencies that both
> semi-regularly break their public APIs at the minor version level and
> sometimes at the patch level. In the long term you would need to
> isolate RDF4J and Sesame with OSGi or Java-9 modules/etc. to keep them
> playing nice together.
Yes, both of these have broken things for me as well. It's weird semantic
versioning is still not followed clearly for such popular libraries.
All Commons RDF modules are OSGi bundles, but this would also need to be
tested more. Do you have any recommendations for what is a good framework
for such integration tests? I think in jena-osgi we used Felix with a Maven
plugin to help run junit tests within OSGi.
> It has worked fairly well for JSONLD-Java so far, which has stabilised
> most of its API for now.
BTW, would you be OK to have a look at the JSONLD-Java module and see if I
am keeping it within the API boundaries? The RDFDataset in jsonld-java
subclasses HashMap, and I had to use that for a couple of the calls (e.g.
deleting quads), which I feel is intruding on implementation details.
(Also I found no methods for adding an existing Quad object, is that on
purpose or a missing feature?)
> RDF4J didn't choose to use the EPL, they are using a BSD-style license
> that Eclipse also support, but the rest of the Eclipse legal
> procedures for contributions are still being used
Brilliant, that should mean we could in theory include RDF4J code/jars
under the Apache license (with appropriate notices).