avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: getting-started.xml
Date Fri, 15 Nov 2002 09:46:10 GMT

Stephen McConnell wrote:
> 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.  

Correct. However notice that Tweety also has "Egg.java", which is even 

I tend to see "reference" not as the complete reference but as snippets 
of it... doesn't make perfect sense though :-|

> 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.

Probably it's a naming issue then, dunno.

Reference in a way that it acts as a reference to at least one aspect of 
the Avalon Framework.

   Egg for example can be used as a reference to lifecycle.
   Tweety as a reference to Container can be a component.

How would you call it? I have difficulty in expressing the concept, 
please help.

>> 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
> ;-)

Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message