ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@cortexebusiness.com.au>
Subject RE: [Vote] Avalon-Framework integration
Date Wed, 09 May 2001 05:06:43 GMT
Ok,

I may as well deal with the most controversial item first. Vven though Pete
said

"I will be avoiding issues that clearly need more research discussion (ie
templating and
preferences) or are controvertial."

I would say Ant adopting Avalon would be somewhat controversial.

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". 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
{
}

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

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.

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. Again an example from Myrmidon

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

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.

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.

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

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.

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.

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

Conor


> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Tuesday, 8 May 2001 10:56 PM
> To: ant-dev@jakarta.apache.org
> Subject: [Vote] Avalon-Framework integration
>
>
> Hi,
>
> For those of you who don't know I am a member of the Avalon
> project. Avalon
> is a project that has two primary aims, developing components and
> developing a framework.
>
> I would like to reuse the framework part of avalon in ant. The primary
> reason is that most of the design patterns in the Avalon Framework are
> things that will be done in Ant. As the patterns are based on extracting
> and cleaning designs from existing component based systems along with
> review of academic research I think they give a strong basis to
> build upon.
>
> Since early september last year I have slowly been getting AvalonFramework
> compatible with what I see as Ant (which caused many a flaming ;]
> ). If you
> look back at Avalons discussion archives you will see that things like
> Configuration was aligned with Ants TOM/ProxyTask, and the container api
> took into consideration the constraints of Ant. So I think that it would
> drastically simplify the building and management of Ant.
>
> When I originally brought this up the reasons not to do it was;
> 1. Framework was still alpha
> 2. Framework was "server-orientated"
> 3. Framework was too big
> 4. Framework didn't "do" anything
> 5. Framework had poor docs
>
> (2) is just plain false - my main use for the framework is geometry
> manipulation and building simulations (ie nothing to do with servers).
>
> (1) was an issue but as of the 11th we will finally be going beta
> - yea!!!!!!
>
> framework with debugging information is 23 kb thus (3) is a non-issue.
>
> (4) is the whole point of framework - it is not meant to do anything ;)
>
> (5) is still partially an issue - we have high level dos describing the
> methodologies and low-level javadocs but no how-tos. Luckily that will be
> our focus post 11th so within a few weeks this will be a non-issue.
>
> If anyone has any queries about Avalon/Framework before voting
> feel free to
> ask (or point out issues).
>
> 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