Stefano Mazzocchi wrote:
>For those who don't know, I'm the person who started this project.
>
>When it started, it was simply called 'java apache server framework', I
>later came up with the name "Avalon" because it's a mythological place
>where King Arthur is supposed to rest in peace. I thought it was an
>ironic way to describe a place that probably doesn't exist: the holy
>grail of software programming: total code reusability and guidelines
>agreed by everyone.
>
>The relatively poor success it had shows that either I was too
>farsighted and things are not happening yet, or it is really a
>mythological place that we'll never reach.
>
1. too farsighted relative to popular demand (but changing progressivly)
2. a niche community attracted and engaged by this very attribute
3. and ramplings of knights in shinning armour, abstract kings and holy
grails (sorry, who was it that came up with the name :-) )
4. and the learning curve
>
>
>Anyway, the project exists and the community is healthy from an apache
>perspective, so everything is good on the ASF front. Everything but one
>thing: nobody seems to have the same vision on what this project is
>about.
>
Ummm, I think that 80% of the cummunity here are behind me when I make
the assertion that this is the best f**** framework out there - period.
And I think a good 70% of the community would back me when I say that
this project is about the maintainece and development of that framework
and ensuring the continuation of the value it delivers. I would go on
to say that 98% of the community are really sensitive to changes -
becuase its addictive - you start using it - you feel something inside
- its a good feeling - your own implementation increases my a factor you
embarised to talk about - you want to continue - there there's no way
you will go back to the old ways. Bottom line 98% of the community want
to maintain that feeling (irrespective of a copule of recent posts)..
Why has this developed - because of some fundimentaly good stuff - and
combined with the community profile - the type of people who spend the
time to overcome the learing curve - there is a willingness to talk
about evolution (ok, talk could be exchanged for strategic engagement).
What I would suggest is that what the project is about has potentially
become blurred by the technical success of what has been delivered.
>
>This is what is hurting the most since I see many people pushing in
>different (sometimes orthogonal) directions. We need to fix this before
>proceeding.
>
> - o -
>
>This project follows a charter I write on the 'request for vote' made on
>the java.apache.org general mail list somewhere around 1998. In case you
>forgot about it, go read it again: you find it in the historical section
>of the docs.
>
>I'll quote the relevant parts here:
>
>
>>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.
>
> - it doesn't state that the project should be dissected into different
>sub-projects
>(NOTE: I think the whole turbine-like subprojecting has hurt Avalon
>*a*lot* expecially in terms of political visibility around the ASF,
>almost everybody at the top think that both Turbine and Avalon are
>somewhat abusing sub-sub-projecting. I totally agree with them.)
>
>But it goes on:
>
If I was preparing a press release I wouldn't use quite the same words -
but the bottom line of your comment concerns fragmentation of the Avalon
brand - and in that respect I agree. As to specfic points I disagree -
but the disagreeement is adademic relative to the point.
>
>>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.
>
>Those who want Avalon to be something else are free to fork it (but not
>using the name Avalon), or propose a vote to change the project charter.
>
I don't think I would like to see the charter changed from the above.
But I do think there is room interpritation of that charter in the
context of the orthoginal interest raised in the other email. In my
head I've an image but it involes circles and I'm not about to but that
into ASCII art this evening.
>
>
>NOTE: this vote will then have to be validated by the Jakarta PMC.
>
> - o -
>
>This said, I can give you an overview of the reasons that brought me to
>write the above.
>
>First of all, without clear guidelines and a solid way to enforce them,
>transparent component portability is not possible. This is why we worked
>hard to define all those empty marker interfaces (that nobody understood
>until we had a working implementation of them, that took more than a
>year!).
>
>But the focus was component portability... but *NOT* across containers,
>across servers!
>
An interesting parrallel is the work that was undertaken CORBA. A
platform was develped that enabled distribution. Over time that
platform engaged a community and spawned multiple implmentations of the
ORB and IIOP specifications. As the market grew, the user community
pushed for portabiliy across different implementations - resulting in
the introduction of an evolution of the ORB and IIOP protocols to enable
interoperability. Only after that event, the CORBA market really grew -
different vendors could differentiate by addressing different needs -
but maintain portability. The indisutry grew by virture of the
defintion of a comon playing field while embracing the value of
differntiation.
>
>
>The original idea was to be able to run many different servers in the
>same JVM and *share* components between them, reducing memory load and
>easying deployment.
>
>Admittedly, in a world where people runs java apps not only on different
>JVMs but also on different machines, that idea was a pretty stupid one
>(didn't have access to big server farms at that time :)
>
>This is also why we had "blocks" and "components": blocks were supposed
>to be sharable by different servers, components were not. Removing this
>need, the difference between the two vanishes (as you guys already
>understood by yourself).
>
> - o -
>
>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
>
1. ECM, a "component" container, apparently going out of fashion
2. Fortress, a component container poised to be the ECM replacement
3. Phoenix, the enterprise level service deployment platform
4. Merlin, delivering an adaptive, embedable vision of a well-formed
compoents
(see CORBA related not above - we have differntiation - we don't have
interoperability)
>
> - 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'.
>
:-)
>
> - o -
>
>What I'd like to see in the future of Avalon:
>
> 1) reunion: Avalon becomes Avalon. One thing. One distribution that
>includes:
>
> - the framework interfaces
> - the framework reference implementation
> - the docs and examples
>
>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]
>
From a brand management perspective this is really valid.
From an development perspective it sucks.
If I had a choice I'd go for brand management.
>
> 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.
>
It's an increasingly popular objective.
>
>That's it. Everything else needs to be moved in more appropriate
>locations.
>
>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).
>
>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) but
>there is a good reason for this:
>
> - the avalon community is fragmented.
>
>I see three major leagues
>
> - pure COP (Peter, Steve, Leo Simons)
>
Does this mean I can give myself a pay-rise or am I one of the eternally
damned?
>
> - cocoon-like COP (Berin, Leo Sutic, Nicola)
> - james (nobody)
>
>In fact, the James community is probably going to drop support for
>avalon and do their own stuff.
>
>Let me tell you this: I *KNOW* that Avalon's best feature is not
>component reusability but patterns reusability... but you don't get this
>unless you learn it the hard way: do your framework once and then try
>Avalon.
>
>I remember Nicola's experience with that: he told me that once he 'got'
>avalon and started refactoring things, everything in his code became
>clearer. It was so nice that he wondered why he didn't code like that
>before.
>
Ummm, so experience here.
>
>But how do you make them use Avalon? by giving users functionality!
>
>and what is the best functionality if not the ability to reuse prebuilt
>components and create your own?
>
+1
>
>That's the marketing strategy I'd like this project to follow: sell
>components to inject the mindset.
>
+1
>
>
>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.
>
+1
>
>
>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.
>
>Please, let's resurrect Avalon as a software, not as a concept.
>
>
+1
Cheers, Steve.
--
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]>
