ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: [Vote] Avalon-Framework integration
Date Thu, 10 May 2001 04:26:14 GMT
At 01:32  10/5/01 +1000, Conor MacNeill wrote:
>> From: Peter Donald []
>> Right - and docs will be done by the time we get to implementing this and
>> you know this ... so whats your point?
>You have kicked us into design phase and you are proposing a vote on the
>adoption of the Avalon framework. Therefore I want to read the
>documentation. This is not available and the documentation that is on the
>web is in fact misleading. How could I vote +1 under these circumstance.

good point - in that case I withdraw the vote till a bit later then. 

>> But as you know that and I have said that a few times ...
>> somethings amiss???
>Besides your manners? No.

well I am sorry if you are offended. But you asked the same question
multiple times and I kind of get the feeling you are ignoring my responses
- this notion may have come through in mail - soz ;)

>> Compression is not an feature of the framework but of the code that uses
>> it. No framework stops you shooting your foot - some make it harder
>Frameworks are the reason the code that uses the framework is compressed. It
>is an inherent feature of frameworks. 

Only OO frameworks - there are other ones that can have minimla compression
(ie component based frameworks) which Avalon tries to be ;)

>It has good and bad points. Don't you
>agree? Highly compressed code for Ant's core would not make Ant easier to
>maintain and extend.


>> >And how have they been tested in Avalon? You just stated above that "Well
>> >considering that Framework has been designed around Ant as a use
>> case this
>> >won't be an issue for us". Considering the usage of Ant, I think it will
>> >get a fair amount of testing. Natural open source effect.
>> I don't understand your point here.
>My point is: You have stated that developing code for Ant would duplicate
>Avalong but be "raw and untested", whatever raw means. The clear implication
>is that Avalon's code is "tested". I am trying to find out how you have
>tested. Where is this code deployed that it has received significant
>testing. You are making assertions and I want to see the facts.

Okay it is based on code from way back (jserv times) that has gradually
been refined. The original developers (Stefano, Pier and Fede) are all
fairly smart and know their stuff. You can actually see many of the ideas
being reflected in industry based standards. ComponentManager stuff is
basically a stripped down version of using JNDI to compose systems (like in
EJB or servlet land), Configuration et al has similar parralels and context
is fairly universal through component land.

About the only things in framework that are not present in numerous other
toolkits/frameworks are Initializable/Disposable/Startable/Pausable. There
is a few toolkits thah have them - Turbine has a parralel Initializable, a
lot of toolkits have Disposable (aka Destroyable) interfaces. As for
startable and pausable - I have seen a few examples of Startable but only
one other example of Pausable. 

There is currently a JSR that aims to formalize the activity methods (ie
Startable/Pausable/Init/disp..) so hopefully that will see their wide
spread adoption.

As for whether it is useful in the context of Ant - I think so. I have
rewritten Ant 3 times so far, first one was a hacked together version that
was uuuugly ;) Second was based on Avalon and was probably the best version
so far. Third version was Myrmidon proposal. In those times I only found
two to three issues (only one was to do with the framework - the rest were
about components). And this one change was something I had been pushing for
practically since last august.

Thus I think it is useful in our context.

>If the framework is not providing the services 

again - just to be clear - the framework does not provide
services/components. It provides schaffolding/framework for design etc.

>you require to implement
>something, if you are driven to hack around it, the implication I draw from
>that is that the framework is perhaps not that mature. You are being driven
>to hack around it's limitations. What is the framework providing? 

framework provides: schaffolding/framework for design

The configuration hack was just that a hack - it has since been migrated
into framework - thankfully. If we came across a similar situation for Ant2
we would just develope a parrallel version in ant.

>BTW, will
>you base a release of Ant2 on an unreleased version of Avalon?

of course not 

>> >I have other concerns. When you build code with a framework, it is like
>> >building a chair with two legs. It only works when the framework supplies
>> >the other two legs.
>> Then you have been subjected to bad toolkits or at least different
>> frameworks. AvalonFramework doesn't do anything at all - by DESIGN.
>So, if it doesn't do anything at all, what exactly does it do?

It provides form framework/schaffolding/patterns

>> It
>> offers a frameowrk to work in or a schaffold for design etc. In technical
>> terms it is a level 2 toolkit with minimal content and maximal form.]
>Can you give me a reference for the definition of a level 2 toolkit?

Not really - should be able to get it by looking through library or more
probably on web. From memory the following levels
0 - does not influence code or data format 
1 - forces user to use a particular data form/content
2 - forces user to use a particular code form/content
3 - hosted components and takes away main entry point 

It is assumed that each levels uses level below it (ie level 2 is also a
level 1) however I have found this not to be the case with certain
component systems (ie MS COM and Avalon/Framework).

>> BTW I can't help but sense you have gone into attack mode. It seems like
>> you don't understand Avalon and thus decided easier to attack.
>How can I understand it when it is not adequately documented. Yeah I know,
>its on the way. How can you propose a vote on adopting Avalon for Ant in
>these circumstances.

I guess I didn't think ;)

>> The fact
>> that all your attacks miss the mark is another indicator that you lack
>> knowledge about domain.
>Don't be condescending. I am not attacking. I am trying to understand why we
>should use Avalon. All I get is assertions.

don't take this the wron way but I assume that you want to agree with the
basic design principles that motivate Avalon/Framework (ie
components/soc/ioc). If you do accept those then my assertions should
naturally follow from looking at javadocs ;) If you don't agree with those
design atterns then speak up now.

Otherwise I will drop this, put up docs and then recall a vote ;)



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message