Stardog plugins

[Zachary]

I've been writing some custom Stardog functions and I had a couple of questions. They're not exactly Stardog specific but I thought you might have some unique insights any that other people might have similar questions.

Any recommendations on how to package plugins, specifically how to deal with plugin dependencies? I created a separate directory server/plugins and added it to the classpath in bin/helpers.sh so just so that I didn't mix things together with the Stardog system packages and then built it as a fatjar/uberjar. It seemed like the best way to avoid dependency issues. I couldn't find much online on the subject regarding ServiceLoader.

I was also looking into the licensing issues involved in using opensource for plugins. I didn't find any definitive reference but it seems like plugins wander into a bit of a grey area as far as the GPL is concerned. My interpretation would be that it's dynamically loaded and isn't sharing core data structures so it's not a derivative work so it's ok to use GPL code in plugins as long as the plugin itself is GPLed. I'm not an expert on this and I'm not sure this is a correct interpretation so I could be completely wrong here. I was just wondering if you had any opinion on the subject and could provide guidance to anyone wanting to write a plugin.

I was planning on making the plugins available on github when I'm finished. They're a collection of basic string metrics/utilities. Would this be a good forum to announce their availability? I was also wondering if there is any general interest in any specific functions from people out there using Stardog. I'm just doing this for a personal project and to get a feel for what you can do.

[Kendall Clark]

On Wed, Dec 9, 2015 at 9:27 AM, Zachary <zachary...@wavestrike.com> wrote:

I was also looking into the licensing issues involved in using opensource for plugins. I didn't find any definitive reference but it seems like plugins wander into a bit of a grey area as far as the GPL is concerned. My interpretation would be that it's dynamically loaded and isn't sharing core data structures so it's not a derivative work so it's ok to use GPL code in plugins as long as the plugin itself is GPLed. I'm not an expert on this and I'm not sure this is a correct interpretation so I could be completely wrong here. I was just wondering if you had any opinion on the subject and could provide guidance to anyone wanting to write a plugin.

​We are okay with that. Since we're not distributing the plugins, GPL isn't a problem for us.​ For any plugin for which someone might want us to distribute it in Stardog, we'd need Apache license (which could be dual license with GPL, of course).​

I was planning on making the plugins available on github when I'm finished. They're a collection of basic string metrics/utilities. Would this be a good forum to announce their availability? I was also wondering if there is any general interest in any specific functions from people out there using Stardog. I'm just doing this for a personal project and to get a feel for what you can do

​.

​Sure​

, feel free to announce it here.

​Cheers,

Kendall​

​

[Michael Grove]

On Wed, Dec 9, 2015 at 9:27 AM, Zachary <zachary...@wavestrike.com> wrote:

I've been writing some custom Stardog functions and I had a couple of questions. They're not exactly Stardog specific but I thought you might have some unique insights any that other people might have similar questions.

Any recommendations on how to package plugins, specifically how to deal with plugin dependencies? I created a separate directory server/plugins and added it to the classpath in bin/helpers.sh so just so that I didn't mix things together with the Stardog system packages and then built it as a fatjar/uberjar. It seemed like the best way to avoid dependency issues. I couldn't find much online on the subject regarding ServiceLoader.

Yeah, I think that's a reasonable approach.  We pull things in via ServiceLoader, so really the only requirement is that the plugin and its dependencies are in the classpath and its registered in META-INF/services.  A fatjar is certainly the easiest way to get stuff into the classpath.  Probably the only thing to watch out for is using different versions of libs, like Guava, that Stardog is already using.

Cheers,

Mike

  

I was also looking into the licensing issues involved in using opensource for plugins. I didn't find any definitive reference but it seems like plugins wander into a bit of a grey area as far as the GPL is concerned. My interpretation would be that it's dynamically loaded and isn't sharing core data structures so it's not a derivative work so it's ok to use GPL code in plugins as long as the plugin itself is GPLed. I'm not an expert on this and I'm not sure this is a correct interpretation so I could be completely wrong here. I was just wondering if you had any opinion on the subject and could provide guidance to anyone wanting to write a plugin.

I was planning on making the plugins available on github when I'm finished. They're a collection of basic string metrics/utilities. Would this be a good forum to announce their availability? I was also wondering if there is any general interest in any specific functions from people out there using Stardog. I'm just doing this for a personal project and to get a feel for what you can do.

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en