Clarify dependencies

[monochromata]

To be able to use jactr without jactr-eclipse and commonreality when embedded without eclipse and commonreality: (1) jactr should not depend on jactr-eclipse and commonreality, (2) jactr-eclipse should only depend on jactr, and (3) commonreality should not* depend on jactr. (* added in an edit)

Anthony: " - we can remove the CR dependency, but it would require the following:

• a jactr runtime specific interface for the clock control mechanism
• a separate bundle to bridge jactr-cr"

[amharrison]

The more I think about this, the bigger of a problem it becomes. The CR dependency isn't really that heavy. jACT-R core uses it for clocks and a common format for processing percepts.

Strictly decoupling jact-r from CR would require rewriting all of the perceptual modules to use yet another abstract representation - which is exactly what CR was designed for. The perceptual modules are no longer consider optional, and as such.. I'd like to keep the dep.

What is the rationale behind the desire to decouple from CR? If you are not using PM modules, the cost of the dependency is negligible.

[amharrison]

One possibility:

• extract support dependencies for CR (from jactr support) into a CR support bundle. (jactr and CR then have separate support bundles)
• extract the clock api/implementations into its own org.commonreality.time bundle
• leave the rest of CR as a monolith bundle (for now)
• we can then separate the PM modules into a separate org.jactr.modules.pm, that depends upon CR core and time.
• jactr core then just depends upon its support and org.commonreality.time

[amharrison]

Additionally..

• I should move org.jactr.launching to jactr-eclipse repo, and probably rename it. This is actually the more general OSGi entry point, so it's not really Eclipse, but more so than core jactr.

[monochromata]

My rationale is to use jACT-R without the existing perceptual motor modules and to embed it into an existing application that runs the jACT-R model in the application process instead of starting a separate process as is done when launching a jACT-R model in Eclipse. I'd use a custom visual module (REMMA) and compute activation values. I wouldn't need motor modules. To speed up installation it would be good if users didn't need to download commonreality and the perceptual-motor modules. (I leave this complication to the end: Eclipse would be the existing application.)

Sorry for being unclear about this in the first place. Adding a layer of abstraction between CR and jactr would not be required. The proposals in your second to last comment fit my case.

[amharrison]

Let me address each of these as separate points. 1) The CR dependency is only adds 1.2Megs (excluding source), and that's with all available bundles (CR core is only 700k). That's smaller that jactr.io. It's file footprint is negligible. And since only the classes needed are ever loaded, it has no performance overhead. 2) Similarly, is install time really an issue? I'm all for a streamlined user experience, but unless you are installing as frequently as you run the model, it seems like a non-issue. 3) Most importantly, the intent you describe is not prohibited at all with the current structure.

• You can embed the jACT-R runtime in pretty much any JVM process (cloud, application, service containers, etc). The core runtime does not require Eclipse or OSGi at all. However, if your model uses a bunch of contributed code, you'll have to ensure it is configured correctly (which you'd have to do anyway). Details are light, but here is a starting point : http://jact-r.org/node/147
• Using the existing PM modules does not prevent embedding.
• The existing PM modules are actually fairly easy to extend and customize.

I am still 100% in favor of cleaning up dependencies. I just want to make sure we are doing it for the right reasons, at the right time, and in the right way.

[monochromata]

1+2) Ok, if resource consumption is not an issue, we do not need to extract separate org.commonreality.time and org.jactr.modules.pm bundles. 3) I'll have a look at org.jactr.embed (and also org.jactr.launching).

This would leave

• extract support dependencies for CR (from jactr support) into a CR support bundle. (jactr and CR then have separate support bundles)
• I should move org.jactr.launching to jactr-eclipse repo, and probably rename it. This is actually the more general OSGi entry point, so it's not really Eclipse, but more so than core jactr.