Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Message-Id: 
 <5.1.0.14.2.20020630190730.00a63020@mail.inspireinfrastructure.com>
Date: Sun, 30 Jun 2002 20:21:39 +0200
To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
From: Leo Sutic <leo.sutic@inspireinfrastructure.com>
Subject: Re: organisation of avalon subprojects
In-Reply-To: <1025444881.1926.30.camel@lsd.bdv51>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

The tendency is to start a subproject (Avalon) and then another subproject 
under that (Excalibur) and then projects under that (MicroContainer) and so 
on. I could devote some hundred lines to this and the reasons for the 
process, but that's neither here nor there...

Anyway, the result is that the scope of the Avalon project has grown 
immensely - it is not just a framework, it is a replacement for RMI 
(AltRMI). It is a Database (AvalonDB). In no way do I want to criticise 
these projects, but do they really belong under the Avalon umbrella? Are 
they really not projects at the same level as Avalon itself?

Another issue with this is that doing this walls us off from the rest of 
Jakarta. Avalon becomes a Jakarta in scope - self-sufficient in itself and 
utterly isolated. I want to see Phoenix-based apps on the front Jakarta 
page. That's the only way to spread Avalon through Jakarta.

As Pete C says, I think we should slim the Avalon project *significantly*. 
And now I am talking about some chainsaw-grade reduction.

With MicroContainer a new possibility has emerged: All Avalon components 
previously in Excalibur can move to Commons. I am currently thinking 
through what restrictions MicroContainer puts on the components it manages, 
but it appears to be quite few. I have already made DataSource work, and I 
think I can do the same for just about any component in Excalibur.

MicroContainer would work with Avalon/Apps, but it seems a bit silly and 
palindromic to provide a non-Avalon wrapper for a wrapper for non-Avalon 
applications...

So I see:

1. framework
Avalon Framework interfaces and reference implementation.

2. containers
2a. common container code (metainfo, etc.)
2b. microcontainer
2c. fortress
2d. phoenix
Again, this is my 3-container approach.

3. component directory
This is a list of components that work with Avalon containers. This is 
basically Apps + Excalibur + all components in Commons that we export from 
Excalibur with MicroContainer. The actual components are *not* stored here 
unless they are wrappers for non-avalon components (like some of the 
current Apps). It is basically a list of "this is the stuff you can put in 
your container.

4. site
5. sandbox

The 4 and 5 is basically just for developers. So a newbie user comes in and 
sees this:

1. Get the framework.
2. Check the list of containers (all 3 of them). Pick one that suits your 
needs.
3. Pick all the stuff you want to put in your container.
4. Good to go!

Like Pete, I'd prefer just one container. But given the different 
requirements for containers I don't think "one single container" will work. 
I do think that all containers will be able to run all components, but the 
way they are managed and the grade of committment to Avalon architecture 
differs - and I do not see how that can be avoided.

Maybe we can provide some three-point checklist for the containers. Like 
(I'm sure we can argue over the list below. I'm only quite certain about 
MicroContainer and its "upper limit" against Fortress. As for the upper 
limit of Fortress, I'm a bit unsure.):

MicroContainer
  + You are primarily interested in using one or two Avalon components in 
another architecture.
  + You are not interested in the Avalon architecture and would like to 
know as little as possible about it.
  + Basically: Just give me the darn component!

Fortress
  + You are considering using Avalon for part or all of your application.
  + Your application is not a stand-alone server or server application.
  + Basically: You are writing a servlet.

Phoenix
  + You are considering using Avalon for a stand-alone server.
  + Basically: You are writing an entire server.

Maybe even a checklist. Check all checkboxes, click on submit, and we'll 
tell you what container you want. :)

Other points:
  + Logkit out of Avalon and to top-level or Commons.
  + Testlet DIE DIE DIE kill it already for the love of God.
  + Excalibur/Event (SEDA/SILK) to Framework or sandbox.
  + Excalibur/Command (SEDA/SILK???) to Framework or sandbox.
  + AltRMI to top-level within Jakarta
  + Rest of Excalibur minus Fortress and MicroContainer to Jakarta-Commons.
  + Concurrent to Commons (already done?) or ditch in favour of 
util.concurrent: 
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html

In short, I want Avalon to be: Framework + Three Containers + Component 
Directory

And nothing more.No Utility package (put it in framework if it is for 
users, in containers-common if it is for container writers (2a on my list 
above), or ship it off to Commons if neither).

That's my perfect world.

And that's all I have to say about that.

/LS


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