ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: [Vote] Avalon-Framework integration
Date Wed, 09 May 2001 05:40:17 GMT
At 03:06  9/5/01 +1000, Conor MacNeill wrote:
>I am -1 on Ant adopting Avalon as a framework for building Ant2 and I give
>the following reasons.
>
>Firstly let me refer to Richard Gabriel's "Patterns of Software - Tales from
>the Software Community". In it he defines the concept of "compression"
>
>"Compression in OO languages is created when the definition of a subclass
>bases a great deal of its meaning on the definitions of its superclass". 

exactly the thing Avalon was designed to avoid actually ;) 

Because we all know OO failed except in particular domains (ie GUIs)
Avalons framework is designed for this exact use case. The solution to
compression is usually sited as Component Based Programming + Aspect
orientated programming. 

Component methodologies assume that there is low depth of inheritance. Some
methodologies (thinking of MSes definition of components) even go to
lengths to guarentee that there is only one level of inheritance. Avalon
does the same.

>He
>contrasts compression with reuse. IMHO, based on the Myrmidon proposal, Ant
>would be highly compressed. The following class from myrmidon is an extreme
>example
>
>public interface Tasklet
>    extends Component, Loggable, Contextualizable, Runnable
>{
>}

In reality those above were done for convenience for proposal, the final
interface would simply look like

public interface Task
{
  void execute() throws Exception;
}

>I would say that is 100% compression. Gabriel goes on to state "Compression
>has clear disadvantages ... Compression is a little dangerous because it
>requires the programmer to understand a fair amount about the context from
>which compressed code will take its meaning. Not only does this require
>available source code or excellent documentation, but the nature of
>inherited language also forces the programmer to understand the source of
>documentation. If a programmer needs a lot of context to understand a
>program he needs to extend, he may make mistake[s] because of
>misunderstandings. Furthermore even if the new code - the compressed code -
>is compact, it will take at least as much time and effort to write as it
>would to write the uncompressed code ..."
>
>Gabriel goes on
>
>"Maintaining compressed code requires understanding its context, which can
>be difficult. The primary feature for easy maintenance is *locality*.
>Locality is that characteristic of source code that enables a programmer to
>understand that source by looking at only a small portion of it."

agree 100% (didn't think I was goin to say that - did you ? 8-] ).

>For me, Gabriel eloquently captures some of the issues in adopting Avalon.
>By adopting Avalon we significantly raise the barrier to entry of new (and
>existing :-) Ant developers. Understanding Ant would require a developer to
>get their head around Avalon too. In general, as Avalon is much more
>generically targetted - that is it is more abstract, this is harder than
>grasping the concrete concepts in Ant. Pete concedes that the documentation
>is lacking so we will be forcing Ant developers into the Avalon source code
>to understand how much of Ant operates.

As I said documentation will soon be fixed so that is a non issue. As I
have also stated if the users extend AbstractTask (or
AbstractContainerTask) they will not have to know that they are even using
Avalon ;)

The only users who will know they are using avalon are the task
engine/project engine developers and perhaps those who want to replace
lovel level things (though 99% of the time they will not need it - much
like 99% of developers don't implement Servlet directly but extend
Generic/Http Servlet).

>Another issue for me is that frameworks force you to work within the limits
>of the framework designer who cannot anticipate every need. You then start
>to work around the framework. 

Well considering that Framework has been designed around Ant as a use case
this won't be an issue for us.

> * Fork of Avalon code that will be folded back when they get equivelent
>facilties.
> * Note that the code is different package so it should not cause any
>issues.

fixed in Avalon - it was always a temporary hack to get proposal out.

>So the framework development starts to spread to the applications which then
>needs to be melded back into the framework. Hopefully all the framework
>users can agree on the changes.

And this is a bad thing why ? This is by design. Patterns should be tested
before being placed in Avalon/Framework. It would be foolish to directly
develope untested patterns in Avalon/Framework - we develope in other
projects. If one becomes particularly relevent then we will reintegrate it
into Avalon to benefit the rest of framework users.

>Another issue is that frameworks sometimes cause you to over abstract.
>Again, as example from Myrmidon which may not be due to Avalon but seems
>overly abstract to me
>The configuration package contains the following classes
>Configurable, Configuration, ConfigurationBuilder, Configurer,
>DefaultConfiguration, DefaultConfigurerm SAXConfigurationHandler.

they were hacks to get around a change in Avalon that I wanted
reintegrated. Avalon/Framework has had these changes integrated and we can
throw them all away except for Configurers. 

The Configurer (in conjunction with converter) is partial replacement for
IntrospectionHelper. The reason is basically because I wanted to support
both Ant1 and Ant2 tasks at least for a transition period. A couple of
times people have wanted to use bean conventions rather than create/add()
so I was going to allow that. If no one did it they could be remerged into
one class.

>I wasn't even sure what all this Configurer stuff was doing. Is this the
>replacement for IntrospectionHelper?

see above.

>One minor aspect I noticed was that the classes derived from the Avalon
>clases seem to be using protected access to the superclass data fields. I
>would have thought that a framework would have fully encapsulated its data
>members.

Yep - mainly as proposal was just bare bones I banged it out fast - the
real method would have a lot more encapsulation (especially AbstractTask*)

>Another issue is that, with Avalon, there will be some changes to Ant which
>cannot be made since they would require changes to Avalon. These either need
>to be worked around as above or deferred until supplied by Avalon. The
>release cycles of Ant and Avalon may become dependent.

Like what ? (Besides which you have an active Avalon develope who can make
sure releases occur to work with ant - if needed - but that isn't expected).

>For me, Ant is a pretty fundamental component which should have minimal
>dependencies on other projects.

We will end up recreating the same things again in Ant that exist in Avalon
- except they will be raw and untested. If you can point out anything that
we don't need in Framework that may be relevent but everythin will be
reused so 

Is there any answers that you aren't satisfied - or does your -1 still
stand - and if so why ?

BTW: If you think *this* is controvertial you should wait to see what I
have to say in future ;)


Cheers,

Pete

*-----------------------------------------------------*
| "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               |
*-----------------------------------------------------*


Mime
View raw message