Kowari on Eclipse

It has been a few months since I last looked at Kowari. My motivations currently are in using a persistent OWL implementation, or at least a persistent RDF store. Kowari’s graph traversal ITQL operations are particularly of interest and look promising, and Paul Gearon, one of the core developers, seems to be working hard on the OWL implementation.

Last time I looked at Kowari, which was a few months ago, it was a tedious process getting it to run inside of Eclipse. I have become accustomed to simply pointing the Eclipse source path at the /src directory in any particular source distribution, and importing all of the jars in the /lib directory, and it all simply working. Not in this case.

The Kowari source code is organised over upwards of 30 separate source folders. When I simply imported all of these folders into eclipse there were serious shadowing problems. For some reason, (which I suspect are an artifact of having a couple of copeting implementations in the source tree, which were configured buy the ant build) there were a number of classes with the same name and package in multiple folders.

Happily, things have improved for the better. Digging into the scr/jar and src/war folder heirarchies reveals folders called “java” which can be imported as eclipse source paths without issue. The only real gotcha here is that a number of source files are generated, and not packaged with the source distro. Running the ant build in situ fixes that. At this point one can add obj/jar/config/java and obj/jar/itql/java to the build path.

At this point the eclipse should be able to build all of the most base parts, as long as you import all of the libraries in lib. A number of errors will be visible due to missing 3rd party libraries.

Running Kowari was a little more tricky. Here is how to do it.

Created a reate a run configuration with main class org.kowari.server.EmbeddedKowariServer. For the command line, I appended the following (adjust the path to suit):

-c file:///D:/mysrc/kowari-1.1/conf/kowari-config.xml

The following are needed VM arguments (again, adjust the path to suit):


-Djava.security.policy=file:///D:/mysrc/kowari-1.1/conf/kowari-rmi.policy
-Dorg.kowari.xml.ResourceDocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
-Djava.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFactory
-Djava.naming.provider.url=rmi://localhost
-Dlog4j.configuration=file:///D:/mysrc/kowari-1.1/log4j-conf.xml

The final trick is to copy the conf directory into whatever your eclipse build directory is (my default is kowari-1.1/classes). This is typically the /bin directory.

My next try was to get the org.kowari.itql.ItqlSession unit test to run. Most of it currently runs without issue, although I am getting failures on testSelect7, and all of hte testLoadAPI, testBaskup, testLoadBackup, and testRestore unit tests. I havent looked into the reasons for this in any detail. In order to get this to run, you will need the VM argument


-Dcvs.root=D:/mysrc/kowari-1.1

The ITQL interpreter, org.kowari.itql.ItqlSession seems to run without any commmand line or VM arguments, although I havent yet tested actually using it. I will update this when I have.

Getting the MP3 demo application required me to run the ant build target

>ant demo-mp3-config-generate

And then adding the obj/jar/demo-mp3/java to the source folders. The MP3 applicatoin is run from the class org.kowari.demo.mp3.swing.Mp3Application with the argument the relative path to the config file: confmp3-config.xml. This should be in your classes/conf dir.

The mp3-config.xml file needs to be edited as below

type =”http://tucana.org/tucana#Model”>

Finally I had to copy the icons in the images directory of demo-mp3 into the /classes directory.