Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Development" <avalon-dev@jakarta.apache.org>
From: "Stephen McConnell" <mcconnell@osm.net>
To: "Avalon Development" <avalon-dev@jakarta.apache.org>
Subject: Avalon Brand
Date: Tue, 3 Apr 2001 19:06:10 +0200
Message-ID: <000201c0bc60$61712060$0a01a8c0@osm.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3.0.6.32.20010403110312.007c29a0@alphalink.com.au>


Peter Donald [mailto:donaldp@apache.org] 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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org