RE: JSON2RDF
I've just added a reference to JSON2RDF in the JARQL Readme. The projects share the limitation of loosing the order of Arrays. But does JSON2RDF support nested arrays? It would be nice to compare the RDF models. Cheers, Reto -Original Message- From: Martynas Jusevičius Sent: Friday, August 16, 2019 6:12 PM To: users@jena.apache.org Subject: Re: JSON2RDF Yes indeed! I’m considering adding built-in SPARQL support as well. Do you know how widely it is used? On Fri, 16 Aug 2019 at 18.08, Reto Gmür wrote: > Hi Martynas, > > This sounds very similar to JARQL which applied the TARQL idea to JSON > in allowing to run CONSTRUCT queries on JSON data. > > See: https://github.com/linked-solutions/jarql > > Cheers, > Reto > > -Original Message- > From: Martynas Jusevičius > Sent: Thursday, August 15, 2019 11:30 PM > To: jena-users-ml > Subject: JSON2RDF > > Hi all, > > just wanted to let you know that in addition to CSV2RDF we've now > published JSON2RDF: > https://github.com/AtomGraph/JSON2RDF > > It's a Jena-based generic JSON2RDF converter which reads JSON and > writes streaming N-Triples output. > Such output is well-suited for further transformation with SPARQL > CONSTRUCT, for vocabulary (re-)mapping, URI building, datatype fixing etc. > > I think the algorithm is similar to JSON-LD but I'm not too sure. In > any case, no @context is necessary as JSON2RDF accepts arbitrary JSON. > > I see JSON2RDF+CONSTRUCT as a more flexible alternative to > JSON-LD+@context when it comes to lifting JSON data to RDF. > > Hope it can be useful. > > > Martynas > atomgraph.com >
RE: JSON2RDF
Hi Martynas, This sounds very similar to JARQL which applied the TARQL idea to JSON in allowing to run CONSTRUCT queries on JSON data. See: https://github.com/linked-solutions/jarql Cheers, Reto -Original Message- From: Martynas Jusevičius Sent: Thursday, August 15, 2019 11:30 PM To: jena-users-ml Subject: JSON2RDF Hi all, just wanted to let you know that in addition to CSV2RDF we've now published JSON2RDF: https://github.com/AtomGraph/JSON2RDF It's a Jena-based generic JSON2RDF converter which reads JSON and writes streaming N-Triples output. Such output is well-suited for further transformation with SPARQL CONSTRUCT, for vocabulary (re-)mapping, URI building, datatype fixing etc. I think the algorithm is similar to JSON-LD but I'm not too sure. In any case, no @context is necessary as JSON2RDF accepts arbitrary JSON. I see JSON2RDF+CONSTRUCT as a more flexible alternative to JSON-LD+@context when it comes to lifting JSON data to RDF. Hope it can be useful. Martynas atomgraph.com
RE: Fuseki OIDC: OpenId authenticated Fuseki access
Thanks Andy. Indeed the packing/unpacking isn't necessary. Another fuseki docker distribution we use (https://github.com/linked-solutions/jena-docker/blob/master/jena-fuseki/Dockerfile) is based on Stian's image and doesn't unpack fuseki. Getting the fuseki jar via maven rather than wget however seems quite convenient so I would like to combine the two approaches. I didn't know that Fuseki has HTTPS support. I usually set this up with the Traefik reverse proxy. I've created a video where I describe how to set up things with Traefik and Keycloak: https://www.youtube.com/watch?v=4jI5GM_AOFs I assumed the SecurityEvaluator also applies to GSP. I can run some tests. You think that posting quads to the default graph could bypass the evaluation? Cheers, Reto -Original Message- From: Andy Seaborne Sent: Thursday, May 30, 2019 4:30 PM To: users@jena.apache.org Subject: Re: Fuseki OIDC: OpenId authenticated Fuseki access Hi Reto, Looks interesting. Fuseki Main should be able to have the Shiro filter added to it which might be a easier way to build the server, rather than unpack/pack. Fuseki main does have read-level access control per graph: https://jena.apache.org/documentation/fuseki2/data-access-control#graph-acl including HTTPS support and endpoint access control. In Fuseki, incepting add/remove Quad is enough though I am not sure about GSP - if the app POSTs to ?default then Fuseki does get the graph and insert data directly, which can bypass quad operations for some link-based datasets. Andy On 24/05/2019 15:46, Reto Gmür wrote: > Hi Jean-Claude > > OpenID Connect is an identity layer on top of OAuth 2. Our solution includes > a Fuseki DataSetAssembler that provides secured datasets, so it doesn't > modifies Fuseki but merely provides an add-on. It also includes a Shiro > AuthenticatingFilter taking care of the authentication part. We provide a > docker distribution of Fuseki with this add-ons. > > Cheers, > Reto > > -Original Message- > From: Jean-Claude Moissinac > > Sent: Friday, May 24, 2019 4:22 PM > To: users@jena.apache.org > Subject: Re: Fuseki OIDC: OpenId authenticated Fuseki access > > Hi Reto > > Interesting > I would like to support such access (or OAuth) Is your solution a modified > version of Fuseki or the integration of some features via the Shiro support > of fuseki? > > Cheers > > -- > Jean-Claude Moissinac > > > > Le ven. 24 mai 2019 à 15:56, Reto Gmür a écrit : > >> Hi all, >> >> At FactsMission we've been experimenting with controlling Fuseki >> access with OpenID (OIDC) authentication and we would like to invite >> you to try out the results and give us feedback. >> >> >>* You may either set up your own instance using the code available >> here: https://github.com/linked-solutions/fuseki-oidc >>* Or, try out our demo-instance here: >> https://fuseki-oidc-sample-client.factsmission.org/ >> >> While you'll need to set up an account to try it out, you can do so >> with any fake email-address as verification is disabled. >> >> Once you logged in with OIDC you will be able to read data from any >> graph but only allowed to write to a specific graph associated with your >> account. >> The motivation for this configuration is to allow guest-book style >> (client-side) applications where user can add and edit entries in >> their personal graph and see the entries from any graph. >> >> Let me know if you find this useful or if we missed something. >> >> Cheers, >> Reto >> >> >>
RE: Fuseki OIDC: OpenId authenticated Fuseki access
Hi Jean-Claude OpenID Connect is an identity layer on top of OAuth 2. Our solution includes a Fuseki DataSetAssembler that provides secured datasets, so it doesn't modifies Fuseki but merely provides an add-on. It also includes a Shiro AuthenticatingFilter taking care of the authentication part. We provide a docker distribution of Fuseki with this add-ons. Cheers, Reto -Original Message- From: Jean-Claude Moissinac Sent: Friday, May 24, 2019 4:22 PM To: users@jena.apache.org Subject: Re: Fuseki OIDC: OpenId authenticated Fuseki access Hi Reto Interesting I would like to support such access (or OAuth) Is your solution a modified version of Fuseki or the integration of some features via the Shiro support of fuseki? Cheers -- Jean-Claude Moissinac Le ven. 24 mai 2019 à 15:56, Reto Gmür a écrit : > Hi all, > > At FactsMission we've been experimenting with controlling Fuseki > access with OpenID (OIDC) authentication and we would like to invite > you to try out the results and give us feedback. > > > * You may either set up your own instance using the code available > here: https://github.com/linked-solutions/fuseki-oidc > * Or, try out our demo-instance here: > https://fuseki-oidc-sample-client.factsmission.org/ > > While you'll need to set up an account to try it out, you can do so > with any fake email-address as verification is disabled. > > Once you logged in with OIDC you will be able to read data from any > graph but only allowed to write to a specific graph associated with your > account. > The motivation for this configuration is to allow guest-book style > (client-side) applications where user can add and edit entries in > their personal graph and see the entries from any graph. > > Let me know if you find this useful or if we missed something. > > Cheers, > Reto > > >
Fuseki OIDC: OpenId authenticated Fuseki access
Hi all, At FactsMission we've been experimenting with controlling Fuseki access with OpenID (OIDC) authentication and we would like to invite you to try out the results and give us feedback. * You may either set up your own instance using the code available here: https://github.com/linked-solutions/fuseki-oidc * Or, try out our demo-instance here: https://fuseki-oidc-sample-client.factsmission.org/ While you'll need to set up an account to try it out, you can do so with any fake email-address as verification is disabled. Once you logged in with OIDC you will be able to read data from any graph but only allowed to write to a specific graph associated with your account. The motivation for this configuration is to allow guest-book style (client-side) applications where user can add and edit entries in their personal graph and see the entries from any graph. Let me know if you find this useful or if we missed something. Cheers, Reto
RE: Getting Symmetric Concise Bounded Description with Fuseki
> -Original Message- > From: Martynas Jusevičius <marty...@atomgraph.com> > Sent: Monday, March 12, 2018 5:11 PM > To: jena-users-ml <users@jena.apache.org> > Subject: Re: Getting Symmetric Concise Bounded Description with Fuseki > > I disagree about SCBD as the default. In a Linked Data context, DESCRIBE is > usually used to return description of a resource, meaning the resource is in > the > subject position. And then bnode closure is added, because otherwise there > would be no way to reach those bnodes. It's not about exploring the graph in > all directions. That a property describes more the subject than the object is not something intrinsic to RDF semantics but a design choice in ontologies. In https://www.w3.org/DesignIssues/LinkedData.html Tim Beners-Lee emphasizes that the description returned when dereferencing a resource must be a full Minimum Self Contained Graph (aka SCBD) for a graph to be browsable. In my opinion it should be possible to build linked data applications for browsable graphs that access the backend only via SPARQL and ideally only with a single query per returned representation. With Fuseki this is possible with a custom handler, GraphDB returns SCBD by default, with Virtuoso and other stores this is a matter of configuration, with Stardog this is not possible. None of this implementations violates the SPARQL specification, in my opinion it's a shame that SPARQL doesn't provide a standard method for returning SCBD, but that's another story. Cheers, Reto > > If you want more specific description, then you can always use CONSTRUCT. > > Some triplestores, for example Dydra, allow specification of the description > algorithm using a special PREFIX scheme, such as > > PREFIX describeForm: > > On Mon, Mar 12, 2018 at 4:40 PM, Reto Gmür <r...@factsmission.com> > wrote: > > > Hi Andy > > > > > -Original Message- > > > From: Andy Seaborne <a...@apache.org> > > > Sent: Saturday, March 10, 2018 3:47 PM > > > To: users@jena.apache.org > > > Subject: Re: Getting Symmetric Concise Bounded Description with > > > Fuseki > > > > > > Hi Reto, > > > > > > The whole DescribeHandler system is very(, very) old and hasn't > > > changed > > in > > > ages, other than maintenance. > > > > > > On 10/03/18 11:44, Reto Gmür wrote: > > > > Hi Andy, > > > > > > > > It first didn't quite work as I wanted it to: the model of the > > resource passed > > > to the describe model is the default graph so I got only the triples > > > in > > that > > > graph. Setting "tdb:unionDefaultGraph true" didn't change the graph > > > the DescribeHandler gets. > > > > > > tdb:unionDefaultGraph only affects SPARQL execution. > > > > > > > Looking at the default implementation I saw that the Dataset can > > > > be > > > accessed from the context passed to the start method with > > > cxt.get(ARQConstants.sysCurrentDataset). I am now using the Model > > returned > > > by dataset. getUnionModel. > > > > > > That should work. Generally available getUnionModel post-dates the > > describe > > > handler code. > > > > > > > I'm wondering why the DescribeBNodeClosure doesn't do the same but > > > instead queries for all graphs that contain the resource and then > > > works > > on > > > each of the NamedModel individually. Is the UnionModel returned by > > > the dataset inefficient that you've chosen this approach? > > > > > > I don't think so - much the same work is done, just in different places. > > > > > > getUnionModel will work with blank node named graphs. > > > > > > getUnionModel will do describes spanning graphs, iterating over > > > named graphs will not. > > > > > > > Also the code seems to assume that the name of the graph is a URI, > > > > does > > > Jena not support Blank Nodes as names for graphs (having an > > > "anonymous node" as name might be surprising but foreseen in RDF > datasets)? > > > > > > Again, old code (pre RDF 1.1, which is where bNode graph names came in). > > > > > > Properly, nowadays, it should all work on DatasetGraph whose API > > > does > > work > > > with bNode graphs. Again, history. > > > > > > If you want to clean up, please do so. > > > > > > > It seems that even when a DescribeHandler is provided, the default > >
RE: Getting Symmetric Concise Bounded Description with Fuseki
Hi Andy > -Original Message- > From: Andy Seaborne <a...@apache.org> > Sent: Saturday, March 10, 2018 3:47 PM > To: users@jena.apache.org > Subject: Re: Getting Symmetric Concise Bounded Description with Fuseki > > Hi Reto, > > The whole DescribeHandler system is very(, very) old and hasn't changed in > ages, other than maintenance. > > On 10/03/18 11:44, Reto Gmür wrote: > > Hi Andy, > > > > It first didn't quite work as I wanted it to: the model of the resource > > passed > to the describe model is the default graph so I got only the triples in that > graph. Setting "tdb:unionDefaultGraph true" didn't change the graph the > DescribeHandler gets. > > tdb:unionDefaultGraph only affects SPARQL execution. > > > Looking at the default implementation I saw that the Dataset can be > accessed from the context passed to the start method with > cxt.get(ARQConstants.sysCurrentDataset). I am now using the Model returned > by dataset. getUnionModel. > > That should work. Generally available getUnionModel post-dates the describe > handler code. > > > I'm wondering why the DescribeBNodeClosure doesn't do the same but > instead queries for all graphs that contain the resource and then works on > each of the NamedModel individually. Is the UnionModel returned by the > dataset inefficient that you've chosen this approach? > > I don't think so - much the same work is done, just in different places. > > getUnionModel will work with blank node named graphs. > > getUnionModel will do describes spanning graphs, iterating over named > graphs will not. > > > Also the code seems to assume that the name of the graph is a URI, does > Jena not support Blank Nodes as names for graphs (having an "anonymous > node" as name might be surprising but foreseen in RDF datasets)? > > Again, old code (pre RDF 1.1, which is where bNode graph names came in). > > Properly, nowadays, it should all work on DatasetGraph whose API does work > with bNode graphs. Again, history. > > If you want to clean up, please do so. > > > It seems that even when a DescribeHandler is provided, the default handler > is executed as well. Is there a way to disable this? > > IIRC all the handers are executed - the idea being to apply all policies and > handlers may only be able to describe certain classes. Remove any not > required, or set your own registry in the query (a bit tricky in Fuseki). > > > Another question is about the concept of "BNode closure", what's the > rationale for expanding only forward properties? Shouldn't a closure be > everything that defines the node? > > It is a simple, basic policy - the idea being that more appropriate ones which > are data-sensitive would be used. This basic one can go wrong (FOAF graphs > when people are bnodes) and does not handle IFP; it does cover blank nodes > used for values with structure and for RDF lists. > > The point about DESCRIBE is that the "right" answer is not a fixed data- > independent algorithm but is best for the data being published. I realize that. My question was more about the definition of "closure". Following forward properties might be a pragmatic approach, the data can often be modelled in such a way that this default implementation of DESCRIBE returns very useful results. But, in some cases even forward properties only, might result in a too comprehensive response. So if the current system doesn't allow disabling the default handler one cannot make this answer smaller (e.g. return a description of instances of ex:Organization without all its ex:hasMember properties). I think fuseki should both allow returning results that contain more as well as less than the default. As for the best default I think SCBD is the best because independently of the data being published and ontologies being used it returns everything the server knows about a particular resource, only stopping the contextual description where the client can get more information with another DESCRIBE query. With SCBD a connected graph can be fully explored with DESCRIBE starting at any resource. Yes the response might be to comprehensive and so there needs to be a mechanism for DESCRIBE handlers to allow responses that are smaller than the default. But I argue that wasting a bit of bandwith in some cases is a better default than arbitrarily limiting information and thus providing too little information in many cases. Reto > > Andy > > > > > Cheers, > > Reto > > > >> -Original Message- > >> From: Reto Gmür <r...@factsmission.com> > >> Sent: Friday, March 9, 2018 3:42 PM > >> To: users@jena.apache
RE: Getting Symmetric Concise Bounded Description with Fuseki
Hi Andy, It first didn't quite work as I wanted it to: the model of the resource passed to the describe model is the default graph so I got only the triples in that graph. Setting "tdb:unionDefaultGraph true" didn't change the graph the DescribeHandler gets. Looking at the default implementation I saw that the Dataset can be accessed from the context passed to the start method with cxt.get(ARQConstants.sysCurrentDataset). I am now using the Model returned by dataset. getUnionModel. I'm wondering why the DescribeBNodeClosure doesn't do the same but instead queries for all graphs that contain the resource and then works on each of the NamedModel individually. Is the UnionModel returned by the dataset inefficient that you've chosen this approach? Also the code seems to assume that the name of the graph is a URI, does Jena not support Blank Nodes as names for graphs (having an "anonymous node" as name might be surprising but foreseen in RDF datasets)? It seems that even when a DescribeHandler is provided, the default handler is executed as well. Is there a way to disable this? Another question is about the concept of "BNode closure", what's the rationale for expanding only forward properties? Shouldn't a closure be everything that defines the node? Cheers, Reto > -----Original Message- > From: Reto Gmür <r...@factsmission.com> > Sent: Friday, March 9, 2018 3:42 PM > To: users@jena.apache.org > Subject: RE: Getting Symmetric Concise Bounded Description with Fuseki > > Great, it works! > > Here's the code: https://github.com/linked-solutions/fuseki-scbd-describe > > Cheers, > Reto > > > -Original Message- > > From: Andy Seaborne <a...@apache.org> > > Sent: Thursday, March 8, 2018 5:35 PM > > To: users@jena.apache.org > > Subject: Re: Getting Symmetric Concise Bounded Description with Fuseki > > > > > > > > On 08/03/18 16:12, Reto Gmür wrote: > > > Thanks for the link ajs6f. > > > > > > The described method for registering with the > > > DescribeHandlerRegistry > > works if Fuseki is embedded. Is there a way to add a > > DescribeHandlerFactory to a stand-alone fuseki instance? ServiceLoaders > come to mind. > > > > ServiceLoaders, or use ja:loadClass. > > > > https://jena.apache.org/documentation/notes/system-initialization.html > > > > > > > > If there isn't such a possibility, what's the best way to embed > > > fuseki with the > > full webapp (Fuseki UI and Admin functions)? > > > > > > > You just need to include it, set environment variables FUSEKI_HOME and > > FUSEKI_BASE, put the files in the right place on disc > "$FUSEKI_HOME/webapp" > > and call the main function. > > > > org.apache.jena.fuseki.cmd.FusekiCmd.main(args ...) > > > > Andy > > > > > Cheers, > > > Reto > > > > > >> -Original Message- > > >> From: ajs6f <aj...@apache.org> > > >> Sent: Saturday, March 3, 2018 5:13 PM > > >> To: users@jena.apache.org > > >> Subject: Re: Getting Symmetric Concise Bounded Description with > > >> Fuseki > > >> > > >> You can replace Jena's DESCRIBE behavior with whatever you like: > > >> > > >> https://jena.apache.org/documentation/query/extension.html#describe > > >> - > > >> handlers > > >> > > >> ajs6f > > >> > > >>> On Mar 3, 2018, at 8:03 AM, Reto Gmür <r...@factsmission.com> > wrote: > > >>> > > >>> Hi all, > > >>> > > >>> I've noticed that a DESCRIBE query returns the Concise Bounded > > >>> Description > > >> (CBD) of a resource, i.e. it expands forward properties to the next > > >> non-blank node. Is it possible to configure FUSEKI to also follow > > >> properties backwards when answering a DESCRIBE query? Or is there > > >> another query that would return that? By using the non-standard > > >> possibility to query for blank-nodes I could get the full resource > > >> context with multiple queries but I would refer to do this with a > > >> single query > > and not to use any non-standard SPARQL feature. > > >>> > > >>> Cheers, > > >>> Reto > > >
RE: Getting Symmetric Concise Bounded Description with Fuseki
Great, it works! Here's the code: https://github.com/linked-solutions/fuseki-scbd-describe Cheers, Reto > -Original Message- > From: Andy Seaborne <a...@apache.org> > Sent: Thursday, March 8, 2018 5:35 PM > To: users@jena.apache.org > Subject: Re: Getting Symmetric Concise Bounded Description with Fuseki > > > > On 08/03/18 16:12, Reto Gmür wrote: > > Thanks for the link ajs6f. > > > > The described method for registering with the DescribeHandlerRegistry > works if Fuseki is embedded. Is there a way to add a DescribeHandlerFactory > to a stand-alone fuseki instance? ServiceLoaders come to mind. > > ServiceLoaders, or use ja:loadClass. > > https://jena.apache.org/documentation/notes/system-initialization.html > > > > > If there isn't such a possibility, what's the best way to embed fuseki > > with the > full webapp (Fuseki UI and Admin functions)? > > > > You just need to include it, set environment variables FUSEKI_HOME and > FUSEKI_BASE, put the files in the right place on disc "$FUSEKI_HOME/webapp" > and call the main function. > > org.apache.jena.fuseki.cmd.FusekiCmd.main(args ...) > > Andy > > > Cheers, > > Reto > > > >> -Original Message- > >> From: ajs6f <aj...@apache.org> > >> Sent: Saturday, March 3, 2018 5:13 PM > >> To: users@jena.apache.org > >> Subject: Re: Getting Symmetric Concise Bounded Description with > >> Fuseki > >> > >> You can replace Jena's DESCRIBE behavior with whatever you like: > >> > >> https://jena.apache.org/documentation/query/extension.html#describe- > >> handlers > >> > >> ajs6f > >> > >>> On Mar 3, 2018, at 8:03 AM, Reto Gmür <r...@factsmission.com> wrote: > >>> > >>> Hi all, > >>> > >>> I've noticed that a DESCRIBE query returns the Concise Bounded > >>> Description > >> (CBD) of a resource, i.e. it expands forward properties to the next > >> non-blank node. Is it possible to configure FUSEKI to also follow > >> properties backwards when answering a DESCRIBE query? Or is there > >> another query that would return that? By using the non-standard > >> possibility to query for blank-nodes I could get the full resource > >> context with multiple queries but I would refer to do this with a single > >> query > and not to use any non-standard SPARQL feature. > >>> > >>> Cheers, > >>> Reto > >
RE: Getting Symmetric Concise Bounded Description with Fuseki
Thanks for the link ajs6f. The described method for registering with the DescribeHandlerRegistry works if Fuseki is embedded. Is there a way to add a DescribeHandlerFactory to a stand-alone fuseki instance? ServiceLoaders come to mind. If there isn't such a possibility, what's the best way to embed fuseki with the full webapp (Fuseki UI and Admin functions)? Cheers, Reto > -Original Message- > From: ajs6f <aj...@apache.org> > Sent: Saturday, March 3, 2018 5:13 PM > To: users@jena.apache.org > Subject: Re: Getting Symmetric Concise Bounded Description with Fuseki > > You can replace Jena's DESCRIBE behavior with whatever you like: > > https://jena.apache.org/documentation/query/extension.html#describe- > handlers > > ajs6f > > > On Mar 3, 2018, at 8:03 AM, Reto Gmür <r...@factsmission.com> wrote: > > > > Hi all, > > > > I've noticed that a DESCRIBE query returns the Concise Bounded Description > (CBD) of a resource, i.e. it expands forward properties to the next non-blank > node. Is it possible to configure FUSEKI to also follow properties backwards > when answering a DESCRIBE query? Or is there another query that would > return that? By using the non-standard possibility to query for blank-nodes I > could get the full resource context with multiple queries but I would refer to > do this with a single query and not to use any non-standard SPARQL feature. > > > > Cheers, > > Reto
Getting Symmetric Concise Bounded Description with Fuseki
Hi all, I've noticed that a DESCRIBE query returns the Concise Bounded Description (CBD) of a resource, i.e. it expands forward properties to the next non-blank node. Is it possible to configure FUSEKI to also follow properties backwards when answering a DESCRIBE query? Or is there another query that would return that? By using the non-standard possibility to query for blank-nodes I could get the full resource context with multiple queries but I would refer to do this with a single query and not to use any non-standard SPARQL feature. Cheers, Reto
Re: Testing of jena-osgi bundle
Hi Stian, On Wed, Jan 14, 2015 at 2:21 PM, Stian Soiland-Reyes st...@apache.org wrote: Thanks for having a look! I don't have write access to the Jena snapshot repository and this is still an open pull request. It should however be here: http://repository.mygrid.org.uk/artifactory/simple/incubator-snapshot-local/ to use it in Maven, add: dependencies dependency groupIdorg.apache.jena/groupId artifactIdjena-osgi/artifactId version2.12.2-SNAPSHOT/version typebundle/type /dependency /dependencies repositories repository idtaverna-incubating/id nameApache Taverna incubating Repository/name url http://repository.mygrid.org.uk/artifactory/incubator-snapshot-local/ /url releases enabledfalse/enabled /releases snapshots / /repository /repositories (hosted outside Apache because Taverna is freshly incubating and haven't got all the apache.org infrastructure set up yet) The other bundle dependencies should be pulled in by Maven, e.g. httpcore-osgi and jackson-core - you might want to check mvn dependency:tree for duplications with your own. As jena-osgi now includes the shadowed classes directly it can also be used as a compile dependency without ever needing jena-tdb etc. I think this might be a problem for us. We provide launchers that do not include TDB but still need some parts of jena (e.g. parsers, serializers, arq). So all launchers include jena-iri, jena-core and jena-arq but the virtuoso launcher does not include jena-tdb. (I deviated from the pattern of having the non-bundle dependencies listed as scopecompilescope - as that means that any Maven users of jena-osgi would also get transitive non-bundle duplicate dependencies like httpclient-cache and jena-arq - or have to add a fragile exclusions as I had to do for httpclient-osgi -- see https://github.com/stain/jena/blob/jena-osgi-bundle/jena-osgi/pom.xml#L117 ) For example usage in Maven, see https://github.com/stain/jena/blob/jena-osgi-bundle/jena-osgi-test/pom.xml#L37 I tried to get the dependencies from the first. But some vriables seem to be inherited and jakckson is not there. It would be really handy to have a (sling launchpad) partials-bundle-list and/or a karaf feature with all the required dependencies bundles. Actually that is what I was trying to do changing https://git-wip-us.apache.org/repos/asf?p=clerezza.git;a=blob;f=provisioning/rdf.tdb/pom.xml;h=4565f118cffeb1d8e5352fce2c1f3ea26f88b443;hb=HEAD to use your bundle. https://github.com/stain/jena/blob/jena-osgi-bundle/jena-osgi-test/src/main/java/org/apache/jena/osgi/test/JenaOSGITestImpl.java In clerezza, which modules do I need to build/run to make a runnable OSGi application? The standalone applications don't run within the OSGi framework as far as I could tell, e.g. platform.launcher.tdb says: TDB variant of standalone java application for launching the clerezza.org platform. It is also a bundle, but there is no OSGi container known to support this (we are working on it :-) ). well yes, this would make an executable jar (shich inluded felix as OSGi container). But the newer approach is in the provisioning folder, e.g. provisioning/launchers/full -launcher Perhaps if you get a clerezza branch configured correctly to use jena-osgi, but something still falls over, you could share it with me to try? I pushed my experiments to a new jena-sogi branch. The easiest is to: cd provisioning mvn install cd launchers/full-launcher mvn antrun:run and acces e.g. localhost:8080/admin/graphs Cheers, Reto On 14 January 2015 at 13:18, Reto Gmür r...@apache.org wrote: Hi Stian Do you happen to have this deployed to a snapshot repository (I don't see it here: https://repository.apache.org/content/groups/snapshots/org/apache/jena/) This would make it a bit easier to try to create a launcher using it. Cheers, Reto On Mon, Jan 12, 2015 at 1:42 AM, Stian Soiland-Reyes st...@apache.org wrote: Would anyone who is using OSGi and Jena be able to test the experimental jena-osgi bundle? I might have asked about this earlier, but have since updated the patch. The ZIP at https://people.apache.org/~stain/jena-osgi-test-20150112/ includes both jena-osgi-2.12.2-SNAPSHOT.jar and the other required bundles (e.g. httpclient-osgi, jackson-core, ++) Note that this email does not in any way form a release - the above is based on the unreleased 'master' branch at Jena. You can build it yourself by checking out my jena-osgi-bundle branch: https://github.com/stain/jena/tree/jena-osgi-bundle and build the jena-osgi/ module with mvn clean install. The bundle JAR would then be in the target/ folder. See details about the Jena pull request below: -- Forwarded message -- From: asfbot notificati...@github.com Date: 12
Re: Testing of jena-osgi bundle
Hi Stian Do you happen to have this deployed to a snapshot repository (I don't see it here: https://repository.apache.org/content/groups/snapshots/org/apache/jena/) This would make it a bit easier to try to create a launcher using it. Cheers, Reto On Mon, Jan 12, 2015 at 1:42 AM, Stian Soiland-Reyes st...@apache.org wrote: Would anyone who is using OSGi and Jena be able to test the experimental jena-osgi bundle? I might have asked about this earlier, but have since updated the patch. The ZIP at https://people.apache.org/~stain/jena-osgi-test-20150112/ includes both jena-osgi-2.12.2-SNAPSHOT.jar and the other required bundles (e.g. httpclient-osgi, jackson-core, ++) Note that this email does not in any way form a release - the above is based on the unreleased 'master' branch at Jena. You can build it yourself by checking out my jena-osgi-bundle branch: https://github.com/stain/jena/tree/jena-osgi-bundle and build the jena-osgi/ module with mvn clean install. The bundle JAR would then be in the target/ folder. See details about the Jena pull request below: -- Forwarded message -- From: asfbot notificati...@github.com Date: 12 January 2015 at 00:05 Subject: Re: [jena] Jena OSGi bundle (#10) To: apache/jena j...@noreply.github.com Cc: Stian Soiland-Reyes st...@mygrid.org.uk Stian Soiland-Reyes on d...@jena.apache.org replies: So I have updated the jena-osgi pull request in #10 https://github.com/apache/jena/pull/10 As commented there - it now includes a new module jena-osgi-test to test it within Equinox and Apache Felix (two of the leading OSGi frameworks). The tests are run as part of the maven build - any failure would be propagated out. It has to be in a separate module in order to test calling from 'another' OSGi module. Note that the test depends on the maven plugin https://github.com/everit-org/eosgi-maven-plugin This is licensed under LGPL. This is only used during the test/build (of jena-osgi-test) - which I believe should be acceptable according to: https://www.apache.org/legal/resolved.html#prohibited Given these brief tests working (which cover jena-core, jena-arq and jena-tdb), I would be comfortable to put it in, then wait for feedback. Perhaps wait with promoting it on the website before we know it works generally? I tried putting it into Clerezza instead of their org.apache.clerezza.ext.jena.* modules, but I am not knowledgeable enough about how to get Clerezza started as an OSGi application.. If you want to copy-paste it into a running OSGi setup, then have a look in jena/jena-osgi-test/target/eosgi-dist/felix/lib as it would contain the bundles you need. Namely: commons-csv-1.0.jar commons-lang3-3.3.2.jar httpclient-osgi-4.2.6.jar httpcore-osgi-4.2.5.jar jackson-annotations-2.3.0.jar jackson-core-2.3.3.jar jackson-databind-2.3.3.jar jcl-over-slf4j-1.7.6.jar jena-osgi-2.12.2-SNAPSHOT.jar jsonld-java-0.5.1.jar libthrift-0.9.2.jar log4j-1.2.17.jar slf4j-api-1.7.6.jar You might not want this if you do slf4j in another way: slf4j-log4j12-1.7.6.jar You should not need these as they are only used for the testing: org.ops4j.pax.tipi.junit-4.11.0.1.jar jena-osgi-test-2.12.2-SNAPSHOT.jar org.everit.osgi.dev.testrunner-4.0.3.jar org.everit.osgi.dev.testrunner.junit4-3.0.4.jar org.ops4j.pax.tipi.hamcrest.core-1.3.0.1.jar — Reply to this email directly or view it on GitHub https://github.com/apache/jena/pull/10#issuecomment-69518840. -- Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/-0001-9842-9718
