I am more concerned about the size of the community here. Is Paul still involved in the code, still wants to be involved, or do we have an SME pool size of 1?
Gary On Nov 16, 2016 11:09 PM, "Benedikt Ritter" <brit...@apache.org> wrote: > I think we can move RDF to Commons regardless of the maturity of the API. > We have other proper components which never had a release. RDF already had > three. > > Benedikt > > Stian Soiland-Reyes <st...@apache.org> schrieb am Mi. 16. Nov. 2016 um > 23:52: > > > Another is that ServiceLoader don't work well under OSGi without careful > > hand holding, so it may be best to leave that to the consumer code rather > > than say have a static method in the API with a fixed ServiceLoader. > > > > (I always have trouble with the ServiceLoader instances built in to Java, > > which become very sensitive to which thread initates first) > > > > It might be worth adding the OSGi service @annotations (or corresponding > > XML files) so RDF implementations can be used as OSGI services; all > Commons > > RDF modules should already be bundles. > > > > OSGi is probably a good fit with Commons RDF as a library can export only > > use of interfaces org.apache.commons.rdf.api, but depend on say RDF4J > > internally or get any RDF implementation injected as an OSGi service; > which > > would not be visible to clients of said library. > > > > And as the Commons RDF API is interoperable, another part of the > > application may use Jena (without knowing it) and pass say a Graph to > said > > library without any problems. > > > > BTW, anchor link didn't work because GitHub and Maven have different > > Markdown flavours, link is instead: > > > > > > https://commonsrdf.incubator.apache.org/userguide.html# > Finding_an_RDF_implementation > > > > As noted in there, care must be taken with reuse of an RDF instance and > > labeled blank nodes: there is no RDFFactoryFactory. > > rdf.getClass().newInstance() should work for anything from a > ServiceLoader > > (but not an OSGi Service which uses proxy classes). > > > > On 16 Nov 2016 10:02 pm, "Peter Ansell" <ansell.pe...@gmail.com> wrote: > > > > > Hi Gary, > > > > > > There is support for java.util.ServiceLoader with the relevant > > > META-INF/services files and default constructors, detailed in the > > > userguide.md file currently, but could also be in README.md: > > > > > > https://github.com/apache/incubator-commonsrdf/blob/ > > > master/src/site/markdown/userguide.md#Finding_an_RDF_implementation > > > > > > However, users may be aware of which implementation they prefer and > > > use it specifically, to match up with their database drivers or other > > > libraries so the direct constructor patterns will be used regularly > > > also. > > > > > > The main reason for that would be that if you use the ServiceLoader > > > approach (just using the RDF interface) you don't have object level > > > access to the mutators to create native Jena/RDF4J/etc. objects out of > > > the Commons RDF objects. There should still be static methods for > > > those cases, but they are less simple to use than the mutators in > > > general. > > > > > > Cheers, > > > > > > Peter > > > > > > On 17 November 2016 at 02:49, Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > In the read me I see a link to an example that has > > > > > > > > public RDF createFactory() { > > > > return new SimpleRDF(); > > > > } > > > > > > > > Is/should a service loader be used to allow pluging in/discovering > > > > implementations? > > > > > > > > Gary > > > > > > > > On Nov 16, 2016 5:22 AM, "Stian Soiland-Reyes" <st...@apache.org> > > wrote: > > > > > > > > Commons RDF (incubating) has been in the Apache Incubator since 2015, > > > > with an aim to graduate into the Apache Commons PMC. I think now > the > > > > time has come to propose such a move. > > > > > > > > > > > > This route was agreed with the Commons PMC at the time, and we have > > > > had good guidance from our mentors, including Commons PMC folks Gary > > > > Gregory, Benedikt Ritter and lately myself :) > > > > > > > > > > > > > > > > > > > > As noted in the 0.3.0 release today, Commons RDF aims to provide a > > > > common Java API for RDF 1.1 graphs and datasets. Commons RDF 0.3.0 > > > > adds API bindings for Apache Jena, Eclipse RDF4J, JSON-LD Java as > well > > > > as a standalone implementation. > > > > > > > > http://commonsrdf.incubator.apache.org/ > > > > > > > > > > > > Now I think Commons RDF is stabilized and is ready to graduate to be > a > > > > component under Commons PMC where we can do a 1.0.0 release to mark > > > > the spot. > > > > > > > > > > > > (Concurrent thread on dev@commonsrdf: > > > > https://lists.apache.org/thread.html/760b2d58e344e51550dcc9f6452395 > > > > efe72e97d3dc06169ef72f09c6@%3Cdev.commonsrdf.apache.org%3E > > > > ) > > > > > > > > > > > > I must admit that community-wise Commons RDF is not as strong as when > > > > the podling started - forming a uniform API across multiple > > > > implementations and use cases did mean many hard technical and > > > > semantic discussions which caused some people to withdraw for a > while. > > > > Several has since returned as indirect contributors (e.g. code > > > > review). > > > > > > > > > > > > Now that the Commons RDF API has settled, and given that Commons has > a > > > > "any ASF committer have write access" policy and an open development > > > > mode, I would like to propose here (and at dev@commonsrdf) that the > > > > component graduate to be owned by Apache Commons PMC. > > > > > > > > > > > > Views..? > > > > > > > > > > > > Here's a project maturity report > > > > https://github.com/apache/incubator-commonsrdf/blob/ > master/MATURITY.md > > > > > > > > > > > > > > > > Want to crunch some code ? Have a look at > > > > > > > > https://commonsrdf.incubator.apache.org/download > > > > https://github.com/apache/incubator-commonsrdf/ > > > > https://commonsrdf.incubator.apache.org/apidocs/ > > > > > > > > > > > > -- > > > > Stian Soiland-Reyes > > > > http://orcid.org/0000-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 > > > > > > > > >
