spaziocodice / jena-nosql Goto Github PK

Apache SOLR binding module.

HBase binding module implementation.

A configuration sub-module (part of the framework module) that must allow several cascading strategies for finding a valid configuration

1st: local file indicated in a system property
2nd: local directory (with fixed filename) indicated in a system property
3rd: classpath resource (with a given name)
4th: embedded (classpath resource) resource (with a given name)

In this way,

• users have many alternatives;
• unit and integration tests can automatically use the 4th strategy

Checkstyle rules will be defined under the project itself.

General-purpose issue for centralizing all development-related facilities.

Creates a flexible and modular (persistent and / or transient) dictionary implementation.

Create a (maven) multi-module project layout with this initial features

• a top level (pom packaging);
• a framework project (jar packaging): that will include classes and components that will be used / implemented in concrete bindings modules;
• a container project for concrete bindings (pom packaging);
• two initial binding projects: one for HBase and one for Cassandra.

Provide a cassandra-backed binding module by using the extension points provided by the framework module.

Write a management mini-framework for decorating (relevant) resources with monitoring and instrumentation behaviour

Periodic code clean-up issue

Instead of having a client library, jena-nosql could be directly used within Solr. That would allow, among other things, a faster and more efficient bulk loading of RDF data.

Fortunately, a lot of things done in CumulusRDF [1] project can be reused (dictionaries, configuration, indexes and so on). I asked them for permissions and they are happy with that.

A couple of points:

1. Here I'll keep things as simple as possible so I don't need a lot of features that are implemented there (e.g. multi-repository)
2. Code cannot be reused as is, mainly because CumulusRDF is using Sesame as RDF framework; in addition there are a lot of features that are not wanted.

[1] https://code.google.com/p/cumulusrdf

Using the Maven assembly plugin and profiles, the project will be able to create a distribution artifact for each kind of supported storage.