On Friday 19 March 2004 02:54, Berin Loritsch wrote: > To which I add, that component to container is only one area. There is > also component to tool, as the example at the top of the list proves.
Wow... You may be closer to 'my camp' than I have imagined. So let's explore my basic principles for a short while. When I say "from component toward container", I mean; 1. The re-usable component is the center of gravity, not the container. The container can change 100 times throughout the lifetime of a component. 2. For components to survive container changes the contracts must be tight (just like they are in JavaBeans). 3. But contracts must be evolvable, replaceable and introduction of new ones. Which means we need a way to define which contracts a component requires vs would like (optional), meaning today's container must be able to know in advance if it is compliant with the requirements. 4. Components are components before they are loaded into a container. That means that there must be a 'primordial contract', which is externally queryable about Identification, Versioning & Compliance. 5. There is no reason why Packaging is not set in contracts as well. New Ear, War, Bar, Sar... Probably not. The fact that we won't need Jars in Jars, probably Jar is fine, and adding a system to how 'other stuff' goes in there in an expandable manner. Point is, it must be possible to define an "API Documentation Contract" where an IDE can look at the 'external component' and know how to integrate the API docs into the view. Finally, Avalon Meta is barely much more than a utility. Jumping up and down over its implementation is ridiculous. Jumping up and down over the @tags that exists is somewhat relevant, but they will evolve. Jumping up any down over the external Meta representation a waste of time. Avalon Meta 1.0 (currently in Merlin) is a specification. We need a system, where that can be slapped on to a component (externally) so that a future-compatible container can query (as in reading an embedded file in the Jar) the component about if that is a Requirement or an Optional Requirement, meaning "What to do if I, the container, is not compliant with the requiment?" THIS is important. An all-encompassing specification won't work, just like all-encompassing applications doesn't work, or all-encompassing classes doesn't work. Decomposition is key. Are we on the same page? If we are, we can proceed with the important stuff, instead of petty arguments over container implementation details and meta tag names. Niclas > > Why do I ask so many questions? > > Because we never learn if we don't. It was a parody on your initial post :o) being a pre-teen kid, who only answer questinos with new questions... Niclas -- +---------//-------------------+ | http://www.bali.ac | | http://niclas.hedhman.org | +------//----------------------+ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
