Definitely a Random Thought:
http://www.jadetower.org/muses/archives/000019.html
Feedback is welcome.
Good essay, nice read. (I don't know how to pronounce it. Never tried so far :D)
"The exciting part of IoC and COP development is not in lifecycles, it's in dependency resolution."
Actually, the way I see it...IoC == top-down dependency resolution.
But COP includes other cornerstones...lifecycle management, configuration management, service discovery. In many applications, you need each of those (the A-F lifecycle is arguably too granular, we don't have much in the way of service discovery, and A-F configuration management remains an absolute gem, the only thing is looking like it'll be a viable competitor is XStream).
COP also seems to be about "packaging", but I think that sucks. IMNSHO there should be a shared standard for packaging that is used for packaging non-COP things as well (@see .Net).
"Break up the Avalon Framework"
Something PeterD once said that I always remembered: Seperation of Concerns and Fragmentation of Concerns are one and the same. The Framework API is already quite small. It can be easily rolled into a single package, and it will still be small (@see DNA). Sure, let's seperate concerns, but haven't we already? The fact that we have a single distributable that does several things is pure pragmatism. An avalon-framework-dependency-resolution-api.jar would be just 3 interfaces and 2 exceptions. That's a bit small :D
"is Avalon about the Framework or is it about a Container?"
It's currently about both. It has also always been about designing and redesigning the balance in the relationship between the two every few months.
IMHO, it should be about delivering on the promise of reuse, even making it rather difficult *not* to reuse. The Framework|Container split is so useful because it allows (in theory; the practice so far has been quite ugly) to keep the framework intact while replacing the container, and still being able to use all the components.
In our ever-changing development world, we currently have "components" using type-0, type-1, type-1.1, type-2, type-3, type-4, type-n IoC, components that aren't IoC at all, javabeans, enterprise beans, eob beans, corba components, soap services, RPC and XML-RPC services, mbeans, singletons, static factories, and others.
Jicarilla is about making (potentially) all of these components work together. And about me being stubborn, ignorant, and arrogant :D
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
