> > This project goals are:
> > - Design and documentation of the Java Apache Server Framework.
> > - Creation and implementation of this framework
> > (interfaces, abstract classes, and shared modules).
> > - Centralized management of the evolution/fixing/patching
> of both the shared code and the framework design.
>
> A couple of things to note:
>
> - it doesn't state that multiple implementations of the framework are
> allowed to be hosted under the same project.
nor does it state that "framework" means interfaces and contracts, and
not implementation.
> - it doesn't state that the project should be dissected into different
> sub-projects
nor does it state that it shouldn't be.
> (NOTE: I think the whole turbine-like subprojecting has hurt Avalon
> *a*lot* expecially in terms of political visibility around the ASF,
yup.
> almost everybody at the top think that both Turbine and Avalon are
> somewhat abusing sub-sub-projecting. I totally agree with them.)
And I disagree. The separation into multiple CVSes and sub-projects is
simply Separation of Concerns applied.
when we have:
jakarta-avalon -- the framework specification
jakarta-avalon-phoenix -- framework implementation
jakarta-avalon-cornerstone -- reusable components for use within phoenix
that seems to be really clean. What happens...
jakarta-avalon-logkit -- logkit used by phoenix. Whether it should exist
or not I'd rather not debate here, again.
xml-cocoon -- publishing framework that uses jakarta-avalon.
and then...
xml-cocoon-avalon-framework-implementation-and-components - the
framework implementation and reusable components of cocoon separated
out. This gets moved over to the avalon project. Note we didn't really
see either phoenix or ECM as a "framework implementation" when this move
happened hence:
jakarta-avalon-excalibur -- reusable components for use with framework
specs.
Of course, stuff like ECM has to do with framework implementation. So
now we have multiple competing implementations and vivid discussion.
Yup, it is suboptimal. It is a little better than never separating out
the stuff in cocoon that it is valuable elsewhere.
> > What the Java Apache Server Framework Is
> > ----------------------------------------
> >
> > It's a design methodology that allows design reuse as well as code
> > reuse between different server projects. These projects gain the
> > advantage of software reuse and the simplicity of developing/managing
> > only the different logic.
>
> This is what Avalon was supposed to be 5 years ago and this is what we
> should have it to be.
<snip>
> Today, Avalon has diluted that concept and became many different things:
>
> - a set of guidelines distilled into java interfaces and patterns
> - many different container implementations
> - a set of components
> - a logging kit
>
> all packaged differently, with fragmented communities, each of them
> approaching the mother community (this list) with a different bias.
>
> No wonder why we can't agree even on some basic things like 'how to get
> the damn component'.
yup. I think it is not so bad that we have not avoided this
fragmentation. Otherwise, Steve would just have forked and kept merlin
internal to the company, or at least decoupled and distant in an unknown
corner of the galaxy.
> - o -
>
> What I'd like to see in the future of Avalon:
>
> 1) reunion: Avalon becomes Avalon.
+1
> One thing.
you mean 4:
> One distribution that
> includes:
>
> - the framework interfaces
> - the framework reference implementation
> - the docs and examples
and
- reusable components for use with the framework
(even if it all moves to commons in the end, as you explain
later, we need this stuff. Just throwing it in with the rest
of the package does little harm.)
> NOTE: that doesn't mean that the JAR file must be unique, we'll have
> 'framework.jar', 'container.jar' and so on, but the 'avalon internal
> names' such as 'Phoenix', 'excalibur' and so on must disappear: we, as a
> community, *DO* *NOT* have the right to create internal subprojects as
> for the jakarta bylaws! [yes, even Turbine doesn't, but since I'm not a
> Turbine developer I can't say anything to them]
we don't?
Anyway, I think having "internal names" can be quite useful (we had
discussion on this a while back) and I would not like to see them
dropped.
> 2) component library: instead of releasing a library of components,
> Avalon should manage its components across the wire. Each component is
> packaged separately. Just like JEdit plugins.
according to what you write above, this is inappropriate as per the
avalon charter. It'd be nice if all of jakarta were to switch to
commons, so we could have commons depend on avalon framework and the
world would be a cool place.
> As for different framework implementations, they can ship the
> 'framework.jar' file and implement what they need differently... but
> they cannot use the Avalon name in their implementation (as for the ASF
> license).
Just like stating "J2EE compatible server" is worth something, stating
"avalon compatible server" can also be worth something, and there should
be some legal way to allow this to happen.
> The above might seem rather brutal (admittedly it is, it wouldn't have
> happened if I had had the time/energy to remain subscribed here)
You mean to say avalon "would not be a mess" if you had never left?
> but
> there is a good reason for this:
>
> - the avalon community is fragmented.
>
> I see three major leagues
>
> - pure COP (Peter, Steve, Leo Simons)
> - cocoon-like COP (Berin, Leo Sutic, Nicola)
> - james (nobody)
nah. Pretty much working together. Berin's writing a book where he uses
the phoenix Pete built as an example; Nicola and me working in unison on
examples, build systems etc; discussions between Steve and the other Leo
must be some of the most interesting ones on the planet....
I think talk of "leagues" and "brutal" is a bit strange. On the one hand
you mention that what we need are (backwards-compatible jadajada)
evolutions instead of revolutions, and then you paint a picture of a
decaying community that is going in the wrong direction.
> That's the marketing strategy I'd like this project to follow: sell
> components to inject the mindset.
uh (scratches head)....marketing strategy? As long as it doesn't have
negative technical consequences....
> Unfortunately, this is much harder with the current way things are
> setup: there is no "avalon" distribution anymore... it has become a
> 'concept'... it's much harder to market a concept than a software
> package you can download, install and play with.
yup.
> Avalon became as thin as 'jakarta'. In fact, the same friction that
> happens over at [EMAIL PROTECTED] happens here: Avalon is a
> project container, not a project anymore. Result: everyone pushes its
> own pet project and things get worse and worse.
nah...things are pretty much getting better and better...
> Please, let's resurrect Avalon as a software, not as a concept.
it's not dead!
I don't know if you notice yourself, but you come across as King Arthur
returing to his golden city, trying to rid it of all the terrible
pollution that has happened in your absence.
There's really no need. Go and sit at that round table again and help
the rest of the people there with the good work they're doing, instead
of trying to point them in a radical new direction which is exactly the
same.
The most radical thing we need is perhaps a treaty with a few other cool
nations. Try and wed princess LogKit to prince Log4J, and you will have
your applause.
We've thrown several containers together (though we're not even sure
what a "container" is yet), and we're now extracting the common stuff
out.
Once there, we can make the other containers as empty a shell as
possible (where the difference between merlin and phoenix might be
expressed in configuration files, the 'dreadful' ECM sent back where it
came from, etc etc.
I'm all for it.
But please, don't go cleaning up when you don't know what to throw away.
cheers,
- Leo Simons
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
