Leo Sutic wrote:
they're not actually circular; it just seems that way. Make the classes-per-jar ratio either small enough or large enough and the problems go away.Berin's "[Excalibur] Release Path" summary triggered an idea in me.Basically, the problem is that we have dependencies all over the place, some of them circular (as Leo Simons discovered a couple of days ago).
been thinking about this. It is _extremely_ difficult to set this up with the current materials. If you want to do this properly it will take lots of time. It is indeed a "[RT]".A solution is to split Excalibur and Avalon into layers, where a layer may only depend on the layers below it.
An example of the complexity: phoenix-client.jar contains stuff used all over the place, to which cornerstone classes sometimes bind quite tightly. Phoenix client is managed as part of phoenix itself, which depends on lots of excalibur libraries. Cornerstone libraries depend on excalibur libraries too.
IOW: you use utility code to build the container (which makes sense)!
The only way to cleanly get out of this is to use rigorous interface-implementation seperation combined with loose coupling between implementation and 'framework' by using an adaptor/wrapping setup. The layers IMV:
NON-FRAMEWORK UTILITY CODE (1)
--------------------------------------
CLIENT FRAMEWORK INTERFACES (2)
--------------------------------------
CONTAINER FRAMEWORK INTERFACES (3)
--------------------------------------
CLIENT FRAMEWORK UTILITY CODE (4)
--------------------------------------
CLIENT FRAMEWORK IMPLEMENTATION (5)
--------------------------------------
CONTAINER FRAMEWORK UTILITY CODE (6)
--------------------------------------
CONTAINER FRAMEWORK IMPLEMENTATION (7)
--------------------------------------
OTHER CODE (8)
(4) & (5) should not depend on (3) but (3) shouldn't depend on (4) and (5) either. So not clean layering. (4)+(5) might be too closely tied in Real Life to seperate them. (8) should ideally tie only to (1)-(3), with the stuff needed from (4)-(7) provided at assembly/deploy time by (7).
(1) -- logkit, commons-collections, etc
(2) -- ServiceManager, Logger, Contextualizable, Parameters,
Instrumentable, BlockContext, etc
(3) -- Container, ServiceDescriptor, etc
(4) -- SAXConfigurationBuilder
(5) -- DefaultContext, DefaultServiceManager, AbstractLogEnabled,
DefaultBlockContext, etc
(6) -- excalibur-logger, baxter, altrmi, etc
(7) -- phoenix, merlin, fortress, etc
(8) -- sevak, cocoon, whatever
The crucial difference with your setup is that (7) indeed can and should depend on lots of (5) and (6).
We're actually sorta close to this in most respects. For example, altrmi and cornerstone and instrument-manager are in #6, and the altrmi dependency on phoenix is actually a dependency on stuff from (2) (ie BlockContext), (3), (4) and (5).
It just doesn't look that way.
The way for getting out of this problem less "cleanly" is to make good use of a software tool which tracks the dependencies for you (like gump), which requires you keep descriptors accurate and up-to-date.
Not saying I am against "doing it cleanly", just that it is something to tackle _after_ we get fortress out. You know, reduce the headache.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
