Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Message-ID: 
 <03334AAF1DF8D2119B1000A0C9E32F58065EFF97@us-pb-xmsg-2.am.sony.com>
From: "Farr, Aaron" <Aaron.Farr@am.sony.com>
To: avalon-dev <dev@avalon.apache.org>
Subject: Clarifying Avalon and Metro
Date: Tue, 10 Aug 2004 12:19:46 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello all.

On the PMC list Noel brought up some good questions about the =
implications
of the Metro proposal, in particular what Metros departure means for =
Avalon.
This email is my attempt to provide answers to these questions.  These =
are
only my personal opinions and I'm interested in starting wider =
discussion on
the matter.

The Metro Vote
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
First off, IMHO the Metro vote is about Metro, not a vote about what =
Avalon
should look like afterwards.  We can work out the Avalon details as we =
go.
I don't believe we need to have everything figured out first and
consequently hold up Metro in the process.

Emerging Consensus
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
There's already been some discussion on Avalon's mission.  I think =
Niclas
started to phrase it well in the recent Cornerstone discussion:

> ... if these [Cornerstone updates] are considered "Go" changes, then=20
> Avalon takes on becoming more of a unifying IoC ground than =
previously,=20
> and one should expect more multi-capable conversions, and perhaps =
even new

> horizontal components entering Cornerstone from Pico & Spring camps.
>=20
> Perhaps we are touching on the Future of Avalon, right here... I am =
not
> sure.

+1

Anton also brought up the point of compatibility and TCKs.  That has =
always
been a tricky thing due to the, well, let's call it "diversity" of IoC
development.  However, it is a goal to keep in mind as we consider the =
steps
ahead.

Avalon Post-Metro
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Following Metro's graduation to TLP status, Avalon will be left with =
the
following bits of code:

   Avalon Framework
   LogKit
   Cornerstone
   Phoenix (inactive, but still in the repository)

Consequently I see Avalon as focusing on two aspects of IoC =
development:
=20
   1. The Avalon Framework

      This involves maintaining and improving the framework, providing
      good documentation and tutorials.  Eventually this could involve
      TCK's for saying a component or container is AF 4.2 or 4.5 or 5.X
      compliant.

   2. Reusable Components

      Maintaining and improving Cornerstone components, preferably =
making
      them as reusable as possible (POJO's) and specifically providing
      Avalon support for these components (perhaps via wrappers or =
whatnot).

I also believe Avalon could provide a fair bit of documentation and
resources on component/container development in general including white
papers, tutorials, framework comparisons, etc.

Concerns
=3D=3D=3D=3D=3D=3D=3D=3D
I'm sure there will be a few.  Despite framework development having =
often
been rocky territory, I believe the elimination of container =
development
from Avalon will actually help the situation.  So this isn't a big =
concern
on my list.

As for component development, I believe there is a need for a component
repository/library in the IoC world but I'm not sure if Avalon is the =
place
for it.  First off, any ASF based repository could run into issues on
distributing non-ASF dependencies such as LGPL'd code.  Secondly, =
managing a
"commons" is not easy and might very well be unrealistic.  But I do see =
the
value in such a project and if there is enough support for it then =
maybe
Avalon should look to fulfill that role.=20

Anyway, those are my thoughts about the situation.  Perhaps I answered
Noel's questions, perhaps I did not.  Thoughts and feedback welcome.

J. Aaron Farr
=A0 SONY ELECTRONICS
=A0 STP SYSTEMS
=A0 (724) 696-7653

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