commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [DISCUSS] Commons RDF as new component?
Date Thu, 17 Nov 2016 07:09:39 GMT
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 <stain@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.peter@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 <garydgregory@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" <stain@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message