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
==============
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
==================
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
> Avalon takes on becoming more of a unifying IoC ground than previously,
> and one should expect more multi-capable conversions, and perhaps even new
> horizontal components entering Cornerstone from Pico & Spring camps.
>
> 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
=================
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:
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
========
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.
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
SONY ELECTRONICS
STP SYSTEMS
(724) 696-7653
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
