On 15 September 2016 at 18:34, Stian Soiland-Reyes <st...@apache.org> wrote: > 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.
Jackson are a bit complex with their policy. They haven't defined their public API at this point so anything could be removed and even public API methods that have been deprecated for two minor versions can be removed. https://github.com/FasterXML/jackson/wiki/Jackson-Releases Apache HttpComponents appear to refer in their release procedures to verifying compatibility with the "baseline release". That seems to mean minor version as the example has xx.yy.00, implying you go back to the first patch version for a minor version and check that you are compatible with it. However, I have still seen cases in the past for the 4.x series where patch versions within a minor version are incompatible so there are still issues with it in practice. https://wiki.apache.org/HttpComponents/HttpComponentsReleaseProcess > 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. I don't use OSGi myself. I have been running around recently submitting pull requests to get upstream Sesame libraries to support RDF4J now that it is out, so I can upgrade my toolchain to RDF4J. >> 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. I will have a look at it. > (Also I found no methods for adding an existing Quad object, is that on > purpose or a missing feature?) I will look into that as RDFDataset should support quads, but may not have a method for insertion right now. >> 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). You would need to email the rdf4j-dev or one of the other eclipse mailing lists to get more advice about legal aspects. Cheers, Peter --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
