Nicola Ken Barozzi wrote:
Stephen McConnell wrote:Leo Simons wrote:On Fri, 2002-11-15 at 08:48, Stephen McConnell wrote:
Maybe it would be a good idea to include in this document some links to some of the other Avalon containers. The current content suggests Phoenix as a starting point which is a little like learning to swim at the deep end of the pool. It could be interesting to reference Tweety and the entry point, followed by Merlin and Fortress dealing with cause grained components, and wrapping up Phoenix at the application level.
Thoughts?
I don't really like it. I feel our documentation should point to
released and easily downloadable software; atm, the only containers with
that status are phoenix and ECM, and I feel it is a good idea to not
stimulate usage of ECM.
Totally agree on the ECM point - however - I concerned about the very high learning curve the Phoenix represents in terms of an entry point. Ok - on Fortress and Merlin there isn't a trealease status for good reasons. On Tweety I think the scenario is different bacause I don't think Tweety should be released - it should be part of the getting started with Avalon walk though. I.e. is about eduction and delivering concrete examples. Does the publication of good informative and eductional content require that we go through a product release procedure? Surely not.
Actually we do, since it's not only documentation but a working implementation of the framework.
We also should decide where it goes, and some have hinted it could go side by side with the framework, although not being in the same package.
IMVHO it could be used as a simple reference implementation of the framework concepts and contracts.
In general I agree. I do however have a problem with referencing Tweety as a reference implementation. The reason is that Tweety demonstrates a flat notion of component deployment - in that it does not have any notion of how to resolve things like dependecies. Without a full implememtation of the Avalon component model - it really cannot be classed as a refernce. In fact, I have a problem with classifying any Avalon container as a reference - Foress does not handle depedencies, Merlin does not handle lifestyle based on marker interfaces, Phoenix does not handle lifestyle at all. I.e. reference implementation is a goal that no container has reached just yet.
Continuing the past proposal about a new unified CVS, thinking out loud: ./src/framework/**.java ./src/reference/**.java ./src/util/**.java ./scratchpad/src/merlin2/**.java ./scratchpad/src/fortress/**.java Thoughts?
Abstracting up just for a moment - yes I'm totally ok with a unified CVS, and I'm all for a scratchpad on the basis that a scatchpad holds all of the non-released projects (Avalon wide).
Cheers, Steve.
p.s. looks like the subject of this thread was fortuitous
;-)
I'm in favour of making things understandable based on useful examples and demonstrations.
Cheers, Steve.
When fortress,tweety etc are released it's a different thing alltogether. cheers, - Leo
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
