Classpath Woes

One of the biggest hassle in Java is managing the classpath. OSGi takes care of some of the problems, but sometimes you still get bitten by FileNotFound or ClassNotFound, and yet the file/class is right there! Here's a checklist of things to look at when it comes to this problem:

1. Is the resource you are trying to access stored under {project}/configuration? This folder is provided as a safe location to stash your resources without having to deal with custom classpaths.
2. Remove the runtime cache ({home}/.jactr/configuration). This is where classpath information is cached so that future runs execute quicker.
3. Clean build?

If none of those fix it, you are facing a problem with projects having to access each other's classpath. Each project has its own classpath that only it can see. If project A depends on project B, A can see into B's classpath, but not the other way around. Most likely the problem you are running into is that B needs to access a resource in A's classpath. The prime example of this is a module (provided by B) needs to read and parse a configuration file (provided by A). B needs a way to peak back inside of A.

If you look in the META-INF/MANIFEST.MF file, you will see how this is accomplished. You're looking for the Eclipse-RegisterBuddy, this tag tells OSGi that the following projects should be allowed to access the project's classpath.

In the above example, everything in CommonReality, core, tools and io can access the project's classpath. This information is in addition to the dependencies. All register buddies must also be in the dependency list. New jACT-R projects automatically have the above register buddies set up.

After you add the project that needs to peek inside the current one, you can update the classpath via the PDE context menu.