Gang, I am not happy about the dependency graph, that Bootstrap depends on Runtime, and because of that a lot depends on Runtime classes (through transitive dependency leak in Maven), which from my angle should be totally hidden to all users.
Now, I refactored this on my local copy, so that Runtime is "discovered" and is theoretically replacable by a re-written Runtime. End of the day, API - the only thing your domain code should depend on. SPI - everything else that the Runtime exposes that can be useful to libraries and extensions. Bootstrap - what the client should use to activate a Qi4j Runtime, declare its behavior and so forth. Runtime - Never have dependency on it. All in all, not much changes from what has been said so far, except that Runtime is now depending on Bootstrap, not the other way around. But some issues pop up; - Layer interface is not implemented by LayerInstance, and there are some mismatches. - First is that the "Model" is not at all exposed. This is possibly good, but then if the Model is NOT part of the Qi4j definition, then the RDF generator and Visualizer should not know about it either. I think we need to decide what parts of the model is really "exposed" from Qi4j, independently of current and future implementations, and nail that down in the SPI and/or some other schema. - Discovery method. There are many ways to "discover" an implementation. Anything from looking at system properties, checking resources on classpath, to even download one which fulfills some constraint expression. There are also room for using various frameworks (OSGi, Spring, app servers) to aid in the discovery process, so I don't think I want it too rigid. Ideas are welcome... When I have the same level of test cases covered I will commit my changes. Hope to finish this before Rickard is back at the wheels... Cheers Niclas _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
