2011/4/27 Alessandro Adamou <[email protected]>: > Hi, > > there seem to be some early adopters who are interested in using Stanbol, > yet would like to run it in non-OSGi environments. > > There is of course an issue about making sure there are alternative > constructors for all SCR services, BundleActivator#start() methods called > etc. > > However now I am mostly concerned about working dir management. By simply > adding all JARs to the classpath and instantiating Stanbol clases, I get > missing Jena resource files such as > > com.hp.hpl.jena.reasoner.ReasonerException: Can't load rules file: > etc/rdfs-fb-tgc-noresource.rules
It's hard to tell how to best solve this without the rest of the stacktrace. As for instantiating the Stanbol classes, the will also probably need to inject the service instance into one another: we use SCR annotations (e.g. @Reference annotated attributes) to perform automated dependency injection. I think it would be rather tedious to do it manually. Adding explicit setters for all the @Reference annotated fields might be possible although it would make the code base slightly more verbose. Do you plan to use all of Stanbol (along with the HTTP / JAX-RS endpoints) or just a restricted subset of the lowlevel components? > We are wondering whether this could be due to the centralized working > directory management in POJO as opposed to distributed (?) working directory > management in OSGi. > > Do you know if compiling with a goal other than bundle would help? mvn > assembly:assembly doesnt seem to work on Stanbol root. To use the assembly goal you need a special declaration in the pom.xml. I would suggest to write your own assembly pom.xml file with the necessary declarations and put all the required stanbol artifacts as dependencies. -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel
