Projects / Avalon / Comments

Comments for Avalon

31 Jan 2002 10:17 berinl

Re: Death by software engineering

> I have some major problems with
> Avalon.
>
> Navigation:
> It creates way too much indirection.
> The Avalon way is that everything but
> everything is named in a config file and
> loaded dynamically, including the things
> that are named in the config file,
> including the things naming the things
> naming the things. Navigating source of
> Avalon-heavy projects is an endless
> scavenger hunt. Wrappers are fine, but
> once your wrappers have wrappers it's
> time to stop.
>

Not everything in Avalon is like that. Perhaps
you are referring to the LogKitManager? You
are not required to use configuration files at all,
but they do help tremendously if (as you say)
you need to get in and get out quickly.

Could you list the Avalon projects you have
personally been in contact, and give a more
concrete example? I find that approach works
more to help me understand what you are
getting at.


>
> Learning curve:
> Avalon documentation on Apache is all
> prose, no Javadoc. Go ahead and check
> it out at
> http://jakarta.apache.org/avalon/framework/
> That's all you get. Furthermore the
> prose is long winded (50 pages) and
> philosophical rather than quick and
> clean. So the only way to interact with
> an Avalon project is through a personal
> committment to learn a whole new
> framework. Learning new frameworks is
> fine, but often way more overhead than
> necessary. A primer and Javadoc are
> badly needed.
>

:/ I've actually been complimented on the
"Developing With Avalon" (http://jakarta.apache.org/avalon/developing-with-avalon.pdf) documenation (50
pages). Many people find that the primer helps
with getting in the mindset of Component
Oriented Programming.

Javadocs are there, but perhaps the links could
be more prominent. We have Javadocs, and
UML diagrams. Check the navigation links,
ther are there.


>
> Modularity:
> Avalon touches every module in a
> system and works its way into every nook
> and cranny of the source. This is the
> opposite of modularity. Once you get
> married to Avalon, there is no
> divorce.
>

Honestly, I find it a good marriage. If you don't
want to implement the lifecycle interfaces (as
I think that is what you are getting at), you can
use AspectJ to do it for you.

All of the Management is moved to the
Container of the Components. This is as it
should be. All components can focus on being
components--without too much inderection.


>
> The net effect of these problems is
> that it is impossible to have casual
> contact with the source of an Avalon
> application. Either you join the Avalon
> religion - and it's more Hare Krishna
> than Unitarian - or you go somewhere
> else. That is bad anywhere, but
> particularly in an open source project,
> where many developers need to get in and
> out quickly.
>

I honestly don't get the analogy here.
Instead of posting these comments on
Freshmeat, perhaps you should subscribe to
the list, and we can work through what your
problems are?

05 Jan 2002 19:56 lucasgonze

Death by software engineering
I have some major problems with Avalon.

Navigation:
It creates way too much indirection. The Avalon way is that everything but everything is named in a config file and loaded dynamically, including the things that are named in the config file, including the things naming the things naming the things. Navigating source of Avalon-heavy projects is an endless scavenger hunt. Wrappers are fine, but once your wrappers have wrappers it's time to stop.

Learning curve:
Avalon documentation on Apache is all prose, no Javadoc. Go ahead and check it out at http://jakarta.apache.org/avalon/framework/ That's all you get. Furthermore the prose is long winded (50 pages) and philosophical rather than quick and clean. So the only way to interact with an Avalon project is through a personal committment to learn a whole new framework. Learning new frameworks is fine, but often way more overhead than necessary. A primer and Javadoc are badly needed.

Modularity:
Avalon touches every module in a system and works its way into every nook and cranny of the source. This is the opposite of modularity. Once you get married to Avalon, there is no divorce.

The net effect of these problems is that it is impossible to have casual contact with the source of an Avalon application. Either you join the Avalon religion - and it's more Hare Krishna than Unitarian - or you go somewhere else. That is bad anywhere, but particularly in an open source project, where many developers need to get in and out quickly.

Screenshot

Project Spotlight

ReciJournal

An open, cross-platform journaling program.

Screenshot

Project Spotlight

Veusz

A scientific plotting package.