Peter Donald [mailto:[EMAIL PROTECTED]] wrote:
Subject: Framework -> Stable ???
[snip]
> Hence I propose that we move the "framework" part of avalon to a stable
> beta release to match c2s going beta. This means that once we commit to a
> particular arrangement we will effectively required to support them for a
> long duration into the future. Given this I think we should do the
> minimalist thing to the greatest possible degree. If a pattern is not
> stable and applicable to a sufficiently wide an audience it should not be
> included in the stable framework.
[snip]
> Given this I propose that the following 2 hierarchies
> * org.apache.framework (stable framework code)
> * org.apache.avalon (unstable/untested code or components)
I am very strongly opposed to this suggestion on brand and marketing
grounds. This sends the message the "AVALON" == unstable/untested. This
reinforces opinion that Avalon isn't ready - irrespective of the actions
taken in achieving a stable framework. Back on the 1-April, Pete posted a
URL to this list referencing an Article all about framework and why they are
needed. This article was arguing the key virtues of global Avalon picture,
and yet the only reference to Avalon was reference at the end of the paper
which stated the following:
Extract, "Frameworks Save the Day", Humphrey Sheil,
http://www.javaworld.com/jw-09-2000/jw-0929-ejbframe.html
"When I began researching this article, I ran across
Avalon pretty early on. It's a framework project under
the Java Apache umbrella that aims to "create, design,
develop, and maintain a common framework for server
applications written using the Java language." Avalon
will be a very powerful framework once it matures, and
its scope goes far beyond anything considered here.
However, I don't think it's ready for prime time, so I
didn't cover it in the article. It's definitely one to
watch, though.
Take a look at this statement and draw some conclusions:
1. "Avalon" has establish brand value
2. "Avalon" brand is aligned with "very powerful"
3. The Avalon process is probably six months off the radar
if your looking for an immediate solution
4. For anyone playing with forward-looking radars, the
"Avalon" brand is the key to track.
While a strongly support the suggestions to establish a stable (potentially
reduced/rationalised) code base I strongly urge everyone to consider the
brand impact that packages play. Changing the main package to a non-Avalon
name will immediately reduce the accrued brand value of Avalon, and will put
in place the framework for progressive degrade of Avalon brand awareness.
Instead on changing packages, I recommend that the package names remains the
same, but that the non-stable parts be repackaged under Avalon
sub-packages - AND that appropriate documentation is provided about
subpackages, purpose, utility, stability, etc.
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
