To try and make things more clear in my mind what Avalon is and where it
stands in relation to what we have been discussing here, I have been
slowly going back through the 'what is...' threads from a while back
and found something that struck be as similar to what we have been
discussing this week:
"I guess the best way to enable sharing would be to get a bunch of people
from different projects that have code in common. Turbine/Jetspeed +
Catalina + Avalon + Slide are the ones that jump out at me but I am sure
there are others. We could then migrate framework-nonspecific code into a
central repository and play though polic to keep backwards
compatability/deprecation trends happening ;)"
This is a pretty close statement to what we have said on library-dev, and
is followed up a few postings later with a discussion of the
infrastructure that would be necessary to get this off the ground. I think
this goes pretty well along what more than a few of us have been saying
( quoted stuff is from the Avalon webpage ):
* Avalon is an existing project that at least started as a framework.
* Avalon has something of an existing codebase that encompasses the
framework and utility classes/components to support that framework.
* In recent months avalon has internally decided to focus on
'components'.
* While this decision has been made somewhere, from the point of view of
an outsider, Avalon is still: "...an effort to create, design, develop
and maintain a common framework for server applications written using
the Java language."
* Avalon has an underlying consistent design method/goal that "will be a
collection of code design patterns, rules, guidelines and suggestions
on how to write server software that "plugs" into the framework."
With this in mind, I don't understand the recurring argument that this
project is a clear duplication of Avalon. So far this project has defined
some fairly clear goals and objectives through the work of people coming
from different jakarta projects, with a road map of how we can get there
slowly developing from these discussions.
What I would suggest is that Avalon focus on remaining that
framework/core. Whatever decisions have been made, the fairly common
perception from outside the group is that "Avalon is a framework for
servers". I am assuming that Avalon has a certain degree of reliance upon
the components that have developed within the framework part of the
project. This is great stuff and gives us a good amount of candidate code.
I don't believe that this should be the only code considered for reuse,
and I think the people who have implemented similar code in the other
jakarta projects deserve a neutral place to work together on these goals
alongside the members of the Avalon community.
David "Stick in the Mud" Weinrich
