Data Folders for NEPOMUK-Java

This page explains in which folders NEPOMUK stores its data. For example, where the RdfRepository keeps its data, or the p2p its index data.

RdfRepository

RdfRepository uses different locations depending on configuration, for end-users a folder in the home-directory is used, for developers the workspace. See data storage folder in the RdfRepository page.

Accessing the Data Folders

Below you find detailled descriptions how to use the data folders, to know which applications stores its data where, see above. == Storing in OSGi bundle data folder== The OSGi standard suggests to store data in the OSGi Bundle's data directory. You get access to this folder when using the BundleContext (passed to the OSGi activator) and the getDataFile() method.

Example: 

public void start(BundleContext context) throws Exception {
  File mydatafile = context.getDataFile("myfile.txt");
  // write/read from mydatafile
}

This is the correct way for OSGi applications to store data, as defined by the generic constraints of OSGi which apply to various platforms (such as embedded devices) where it is often unclear how to find a filesystem.

During development, the folder will be something like: 

C:\workspace_psew\.metadata\.plugins\org.eclipse.pde.core\PSEWCompleteProduct.product\org.eclipse.osgi\bundles\19\data

Problems with OSGi bundle data folder

There are two problems connected with the getDataFile() method:

  • The data is deleted when starting the application with the -clean option. This often happens during debugging.
  • The data is not accessible when the plugin is updated/replaced. Different versions of the same plugin get different plugin IDs, and the data folder is bound to the ID.

Consequently, the call to getDataFile() ends up in org.eclipse.osgi.internal.baseadaptor.BaseStorageHook#getBundleStore() which is (as of version 3.2, 1.6.2006) implemented like this: 

	public File getBundleStore() {
		if (bundleStore == null)
			bundleStore = new File(storage.getBundleStoreRoot(), String.valueOf(bundleData.getBundleID()));
		return bundleStore;
	}

The bundle ID is encoded here, and there is no configuration value that may replace it with the bundle-plugin-ID string, which remains constant.

The two problems weren't solved for Eclipse, as you can see in these two bug reports:

The user's data directory

Desktop applications commonly store data inside the user's home directory (on *nix, this is ~/ which points to /Users/<username> or /home/<username>, on windows this is C:\Documents and Settings\<username>, we furthermore refer to it as ~).

The user's home folder is accessiable via the Java system property "user.home". NEPOMUK stores all its data in a subfolder named ".nepomuk", which is also considered best practice for most unix applications. The (neglectable) caveat is that we don't conform to the native OS's best-practice folders (on windows, "local data", on Apple the "library").

The Eclipse workspace

Eclipse manages to store Bundle information in a workspace, any typical workspace/.metadata/.plugins/ folder, such as workspace/.metadata/.plugins/org.eclipse.jdt.core contains the data for Eclipse plugins and keeps it independent of OSGi plugin changes.

Access to this folder is not part of the OSGi standard and specific to Eclipse. Starting point for this is ResourcesPlugin?.getWorkspace().getRoot(). You'd need to add org.eclipse.core.resource* and org.eclipse.core.filesystem* plugins to target platform, and add the following in product's config.ini before rdf repository: 

 org.eclipse.equinox.registry@3:start,\
 org.eclipse.equinox.preferences@3:start,\
 org.eclipse.core.contenttype@3:start,\
 org.eclipse.core.resources@4:start,\

For example, you can get some temporary directory new URI(ResourcesPlugin.getWorkspace().getRoot().getLocationURI().toString()+"/org.semanticdesktop.myservice")

You should stick to the Eclipse standard here and use the Bundle-SymbolicName? as parameter, for example "org.semanticdesktop.nepomuk.comp.rdfrepository".

Storing data in the Eclipse workspace is not used by NEPOMUK components and at the developer's own risk.