First off, thank you Noel for you message - a checkpoint well heeded.
Pete - thank you for kicking of direction from within that context.
See notes in-line:
Peter M. Goldstein wrote:
All,
I'd like to second the sentiment and message conveyed by Noel. As yet
another committer on an Avalon-dependent project and a long-time lurker
on the Avalon developers' list, I've been extremely concerned by the
recent threads on the list. While conflict is often constructive, I
don't believe the recent threads serve the general good.
There's one point that Noel made that I'd like to expound upon further.
If this means that there needs to be cleaner lines drawn regarding
sub-projects such as Cornerstone and Excalibur, then draw them and
be done with it. If they are available for ANY containers to use,
then they are equally shared. If they are part of a given
container's domain, make it clear and let the other containers
clone them now.
As I see it this, as much as the personality conflicts, is the root
problem.
Cornerstone has and remains an obsticle - cleaning this one up would go
a long way to eliminating an point of technical friction. A simple vote
on Cornerstone positioning relative to Avalon and its sub-projects would
highly benefitial. Excalibur on the other-hand, is generally speaking,
well broken out in terms of functional units, but drawing the lines will
require a more engagement/attention that the Cornerstone issue.
We have a couple (perhaps more than a couple) of different visions of
what features and behaviors an Avalon container should provide. That's
good. Contrasting visions, when brought to the larger community, can
help drive innovation and product development. No one has a monopoly on
good ideas (and, as is less often stated, no one is immune from at least
the occasional bad idea).
We have strong personalities driving those visions. That's also good -
strong advocates are important. Otherwise ideas die on the vine.
What we don't have is a clear exposition of those visions, their points
of intersection, and their points of divergence. Maybe other people on
this list feel differently, but I believe that a lot of this could be
resolved by a frank and open technical discussion under Apache
guidelines. I'm still not clear what specific goals the members of each
group are trying to achieve. It would also be an opportunity for those
of us who are Avalon consumers to bring to the developers' attention
some of the things that we find most confusing/inadequate (i.e.
identity/typing of objects provided in the context).
The goal of this discussion would be to precisely delineate what falls
into the framework and what does not. The framework constitutes the
common services available in and behaviors provided by all Avalon
containers. Note that the Framework is not only the set of interfaces,
but is also a clear statement of the container-component contracts that
those interfaces represent.
+1
Anything outside of the framework scope may or may not be provided by a
container. "Extras" provided by a particular container may later make
it in (perhaps in altered form) to a later rev of the framework. Anyone
who writes code that depends on a container-specific feature is
committing themselves to that container. This is exactly how the world
of commercial app servers works.
+1
Rephrasing this in a schematic:
|----------------------------------|
| Avalon Framework Client API | <-- standard (current framework)
|----------------------------------|
| Avalon Framework Container API | <-- standard (future)
|----------------------------------|
| Xxxxx Container Propriatory API | <-- custom container added value
|----------------------------------| (Phoniex, Merlin, ...)
As far as the impact on the codebase, the end result of such a
discussion would be a set of framework classes and Apache/Jakarta
commons classes which are common, and several sets of container specific
classes in different, non-conflicting container specific packages. In
the end, render unto Framework what is Framework's, Commons what is
Commons, Phoenix what is Phoenix's, and Merlin what is Merlin's.
Yes, such a discussion would be a distraction from writing code. And
some tend to view discussions like this as a waste of time. But Avalon
has grown into a diverse and active community, with a number of
"customers". That means it needs to devote real time to discussion of
these high-level issues. Otherwise, IMHO, more lovely and unproductive
email battles are inevitable.
I would really like to see something like this go into a document(s),
with input from users with different priorities (a.k.a. viewpoints and
usage scenarios). So take my +1 as a "I agree and I'm willing to put
effort into it".
On a not quite related note, another reason for this discussion is that
it might serve as the basis of new Avalon marketing documentation. This
marketing effort would serve to solidify current users and attract new
ones. This would help spread the Avalon vision as well as making Avalon
evangelizing easier for those of us on products where there is a "ditch
Avalon" movement. Just a thought.
+100
Also willing and able to contribute to this.
Cheers, Steve.
--Peter
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
