Sometimes after upgrading a workspace or an installation (including creating a new install), Eclipse gets confused and hoses things it shouldn't. A common problem is to see a slew of bundle resolution errors in the Manifest.MF, where before there were none. 

Merely go to Preferences - Plugin Development - Target Platform. Most likely it will be empty. Just click to restore defaults and save. 

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.

Bugs happen. Particularly in research software, no matter how many best practices you observe (or ignore). This is how you should submit a problem.

1. Make sure you can reliably reproduce the error. If you can't, no one else will either.
2. Spend sometime trying to localize where the problem is. The entire source for jACT-R is included. If you look in the Plugin Dependencies folder of your project, you'll see org.jactr_xxxxxxxxxxx.jar, open it up. Packages are organized along theoretical lines. Problem with production instantiation? check org.jactr.core.production or org.jactr.core.module.procedural. Problem with the visual module? check org.jactr.modules.pm.visual. You get the idea. 
3. When you have an idea as to where the problem might be, turn on the architectural logging. In the root of your project is a jactr-log.xml file. It allows you to enable/disable logging at the package or individual class level. Turn it on for where you think the problem is and examine the log output. If you see where the problem is, mark it in the file. You may need to turn on logging in the run configuration as well.
4. If it doesn't contain sensitive information, or that information can be scrubbed out, export your project along with the run configuration and relevant log files to an archive file. 
5. Submit a bug report with as much detailed information as possible. 
   1. What is the expected behavior of the model
   2. What is the observed behavior of the model
   3. Steps to reproduce
6. For extra credit, you can reimport jactr into your workspace, try to fix it yourself and attach your recommended patch.

You can submit your bug reports to the GitHub site for each subcomponent:

1. jACT-R Core proper
2. jACT-R Eclipse interface