avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject What is Avalon?
Date Thu, 20 Jun 2002 23:12:55 GMT
For those who don't know, I'm the person who started this project.

When it started, it was simply called 'java apache server framework', I
later came up with the name "Avalon" because it's a mythological place
where King Arthur is supposed to rest in peace. I thought it was an
ironic way to describe a place that probably doesn't exist: the holy
grail of software programming: total code reusability and guidelines
agreed by everyone.

The relatively poor success it had shows that either I was too
farsighted and things are not happening yet, or it is really a
mythological place that we'll never reach.

Anyway, the project exists and the community is healthy from an apache
perspective, so everything is good on the ASF front. Everything but one
thing: nobody seems to have the same vision on what this project is
about.

This is what is hurting the most since I see many people pushing in
different (sometimes orthogonal) directions. We need to fix this before
proceeding.

                                     - o -

This project follows a charter I write on the 'request for vote' made on
the java.apache.org general mail list somewhere around 1998. In case you
forgot about it, go read it again: you find it in the historical section
of the docs.

I'll quote the relevant parts here:

> This project goals are: 
>  - Design and documentation of the Java Apache Server Framework.
>  - Creation and implementation of this framework 
>    (interfaces, abstract classes, and shared modules).
>  - Centralized management of the evolution/fixing/patching 
     of both the shared code and the framework design.

A couple of things to note:

 -  it doesn't state that multiple implementations of the framework are
allowed to be hosted under the same project.

 -  it doesn't state that the project should be dissected into different
sub-projects 
(NOTE: I think the whole turbine-like subprojecting has hurt Avalon
*a*lot* expecially in terms of political visibility around the ASF,
almost everybody at the top think that both Turbine and Avalon are
somewhat abusing sub-sub-projecting. I totally agree with them.)

But it goes on:

> What the Java Apache Server Framework Is
> ----------------------------------------
>
> It's a design methodology that allows design reuse as well as code 
> reuse between different server projects. These projects gain the 
> advantage of software reuse and the simplicity of developing/managing 
> only the different logic. 

This is what Avalon was supposed to be 5 years ago and this is what we
should have it to be.

Those who want Avalon to be something else are free to fork it (but not
using the name Avalon), or propose a vote to change the project charter.

NOTE: this vote will then have to be validated by the Jakarta PMC.

                                 - o -

This said, I can give you an overview of the reasons that brought me to
write the above.

First of all, without clear guidelines and a solid way to enforce them,
transparent component portability is not possible. This is why we worked
hard to define all those empty marker interfaces (that nobody understood
until we had a working implementation of them, that took more than a
year!).

But the focus was component portability... but *NOT* across containers,
across servers!

The original idea was to be able to run many different servers in the
same JVM and *share* components between them, reducing memory load and
easying deployment.

Admittedly, in a world where people runs java apps not only on different
JVMs but also on different machines, that idea was a pretty stupid one
(didn't have access to big server farms at that time :)

This is also why we had "blocks" and "components": blocks were supposed
to be sharable by different servers, components were not. Removing this
need, the difference between the two vanishes (as you guys already
understood by yourself).

                                 - o -

Today, Avalon has diluted that concept and became many different things:

 - a set of guidelines distilled into java interfaces and patterns
 - many different container implementations
 - a set of components
 - a logging kit

all packaged differently, with fragmented communities, each of them
approaching the mother community (this list) with a different bias.

No wonder why we can't agree even on some basic things like 'how to get
the damn component'.

                                 - o -

What I'd like to see in the future of Avalon:

 1) reunion: Avalon becomes Avalon. One thing. One distribution that
includes:

      - the framework interfaces
      - the framework reference implementation
      - the docs and examples

NOTE: that doesn't mean that the JAR file must be unique, we'll have
'framework.jar', 'container.jar' and so on, but the 'avalon internal
names' such as 'Phoenix', 'excalibur' and so on must disappear: we, as a
community, *DO* *NOT* have the right to create internal subprojects as
for the jakarta bylaws! [yes, even Turbine doesn't, but since I'm not a
Turbine developer I can't say anything to them]

 2) component library: instead of releasing a library of components,
Avalon should manage its components across the wire. Each component is
packaged separately. Just like JEdit plugins.

That's it. Everything else needs to be moved in more appropriate
locations.

As for different framework implementations, they can ship the
'framework.jar' file and implement what they need differently... but
they cannot use the Avalon name in their implementation (as for the ASF
license).

The above might seem rather brutal (admittedly it is, it wouldn't have
happened if I had had the time/energy to remain subscribed here) but
there is a good reason for this:

 - the avalon community is fragmented.

I see three major leagues

 - pure COP (Peter, Steve, Leo Simons)
 - cocoon-like COP (Berin, Leo Sutic, Nicola)
 - james (nobody)

In fact, the James community is probably going to drop support for
avalon and do their own stuff.

Let me tell you this: I *KNOW* that Avalon's best feature is not
component reusability but patterns reusability... but you don't get this
unless you learn it the hard way: do your framework once and then try
Avalon.

I remember Nicola's experience with that: he told me that once he 'got'
avalon and started refactoring things, everything in his code became
clearer. It was so nice that he wondered why he didn't code like that
before.

But how do you make them use Avalon? by giving users functionality!

and what is the best functionality if not the ability to reuse prebuilt
components and create your own?

That's the marketing strategy I'd like this project to follow: sell
components to inject the mindset.

Unfortunately, this is much harder with the current way things are
setup: there is no "avalon" distribution anymore... it has become a
'concept'... it's much harder to market a concept than a software
package you can download, install and play with.

Avalon became as thin as 'jakarta'. In fact, the same friction that
happens over at general@jakarta.apache.org happens here: Avalon is a
project container, not a project anymore. Result: everyone pushes its
own pet project and things get worse and worse.

Please, let's resurrect Avalon as a software, not as a concept.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message