This is a strange problem that I have yet to track down. It appears to be a bug in Eclipse's caching of classpath data. One instant everything is working fine, but suddenly (and forever after), the classpath gets corrupted and the runtime will be unable to find your model even though it is on the classpath. Through some digging, a temporary fix is available.
Actually, this will result in the loss of your Target Platform, but that can be fixed here.
If this problem still persists, it suggests that there is a lower level dependency resolution failure of an option dependency. These are not normally reported because they are at a lower level. Check ${userHome}/.jactr/configuration/${projectName}/${runConfiguration}-actual/${timestamp}.log for any errors.
Setting the model's EnablePersistentExecution parameter to true will enforce conflict resolution when there is no goal and no pending events.
Models that are entirely internal (i.e., they are not reactive to the external world), can use the internal event queue to determine when it can possibly fire again. To enable this, set the model's EnableUnusedCycleSkipping parameter to true.
Be warned, though - if the model is connected to another system for its perceptual world, the model will skip cycles, making the detection time wonky.
Ah, now this is a problem that I run into regularly. Here's the deal: it's not a bug and it's not a memory leak. Almost all communication in jACT-R is asynchronous. This allows the model to run instrumented with (relatively) little performance impact. The problem arises when the model is actually running too fast (and producing too much data) for the IDE to keep up with. When this happens, network buffers rapidly start filling up and memory is consumed at an alarming rate. The two process then start butting against the resource limits and performance crawls to a halt - potentially with out of memory errors.
This problem most often occurs when persistent execution is on and cycle skipping is off. Basically, your model is plowing through a lot of worthless cycles and generating a bunch of data that is worthless. The IDE chokes on the volume and kaboom.
Your best bet fix is to enable the SynchronizationManager instrument in the run configuration. This will force message synchronization at a periodic (and configurable) rate.
Ok, so you have built your awesome model, tested it, hardened it, and it looks amazing. Now you decide it is time to embed the model in your game engine, or whatever. How do you trim the bloat of the IDE and get just what you need in the arch?
None of the jACT-R core or modules actually depends upon Eclipse or OSGi, rather it is the launchers that do. To effectively embed, you just need to place the core dependencies on the classpath and build a launcher suitable for your needs.
(note: I am working on some code to make this easier, but it is far from ready. If you want to code as it is, just ask)
The simplest solution is just to use org.jactr.entry.Main as a starting point. It's the same entry point the Eclipse launcher uses, but only after it has dynamically hooked up all the extensions (i.e. parsers, compilers, automatic code injection).
However, if you do require custom parsers, or any of the other dynamically resolved elements, you will have to do so yourself, with calls such as : ModelParserFactory.addParser(String extension, Class extends IModelParser> clazz) or ASTParticipantRegistry.addParticipant(String moduleClassName, IASTParticipant participant)
Additionally, you will likely require finer-grained control of the run cycle. org.jactr.tools.throttle.RuntimeThrottler (sorry, no javadoc yet) provides an example of how to limit the cycle time. It can also be adapted to run for one cycle and wait until signaled to run another.
jACT-R did support command line execution back in the day. It was meant to make it easier to execute in "lighter" environments (i.e., within a game engine, controlling a robot, on a cell phone, whatever). As time progressed, it became clear that a general solution for that was at odds with the primary use case: modelers trying to build and analyze their particular phenomenon.
The primary use case relies heavily upon OSGi and Eclipse's dynamic and modular tools. These, however, make traditional command lines much more difficult (and unwieldy). OSGi and Eclipse dynamically check project dependencies and securely set up the various classloaders and resource paths, as well as extensions (for parser, compilers, modules, extensions, etc.) and the actual runtime environment.
This does not mean that you can't run from the command line. You can, but it is a really bad idea to use that mode for the development of a model. Only after you have built, tested, and hardened your model in the IDE should you even think about embedding or command line execution.
Let's assume your model is the awesomsauce and you want to run it command line now. First, you will need the environment.xml file that the IDE generated in the run directory. This tells the org.jactr.entry.Main entry point how to assemble the environment. You will want to strip out the attachments : org.jactr.tools.async.controller.RemoteInterface and org.jactr.tools.tracer.RuntimeTracer, as they are only for IDE runs.
Next, you need the command line that Eclipse uses. To do this, run your model, switch to the debug view and bring up the properties of the running processes. It will include the actual command line. It looks something like this:
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java -Dorg.apache.commons.logging.log=org.apache.commons.logging.impl.Log4JLogger -Dlog4j.configuration=file:/Users/harrison/Archive/Development/workspaces/modeling-dev/mil.navy.nrl.ncarai.associative.fan/jactr-log.xml -Dfile.encoding=MacRoman -Xbootclasspath/p:/Users/harrison/Archive/Development/Apps/3.7/eclipse-model-dev-32/plugins/org.eclipse.jdt.debug_3.7.100.v20120529-1702/jdi.jar -classpath /Users/harrison/Archive/Development/Apps/3.7/eclipse-model-dev-32/plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar org.eclipse.equinox.launcher.Main -application org.jactr.launching.application -data /Users/harrison/.jactr/workspaces/mil.navy.nrl.ncarai.associative.fan -configuration file:/Users/harrison/.jactr/configuration/mil.navy.nrl.ncarai.associative.fan/Embodied-Fan-actual/ -dev file:/Users/harrison/.jactr/configuration/mil.navy.nrl.ncarai.associative.fan/Embodied-Fan-actual/dev.properties -name jACTR -nosplash -os macosx -arch x86 -e file:/Users/harrison/Archive/Development/workspaces/modeling-dev/mil.navy.nrl.ncarai.associative.fan/runs/8.16.12/9.49.28AM/environment.xml
There's a lot of mess in there. Let's break it down.
That will get you up and running on the command line, but again, I don't recommend it. The IDE provides you a ton of tools that will help you understand your model. Command line ninjas will always be at a disadvantage here.