You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@osm.net> on 2001/04/03 19:06:10 UTC
Avalon Brand
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
RE: Avalon Brand
Posted by Peter Donald <do...@apache.org>.
At 07:26 4/4/01 +1000, Peter Donald wrote:
>At 08:43 3/4/01 +0200, Leo Simons wrote:
>><snipped>
>>> To that end, I propose the following heirarchy:
>>>
>>> org.apache.avalon (stable subpackages and interfaces, etc.)
>>>
>>> org.apache.avalon.untested (packages and classes, etc under development)
>>
>>This seems the better solution from a marketing POV. Also, it
>>removes some duplicity in naming (when accessing cvs, new users
>>might think "framework? I thought Avalon was the framework". I
>>just saw an existing user think that =).
>>
>>Perhaps it shouldn't be "untested" but "alpha" or
>>"development". Doesn't matter that much. My +1.
>
>I would prefer a whole other name/brand for that ...
>org.apache.???.*
or maybe org.apache.avalon.framework.* for framework (which is stable) and
org.apache.avalon.* for the rest???
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Avalon Brand
Posted by Peter Donald <do...@apache.org>.
At 08:43 3/4/01 +0200, Leo Simons wrote:
><snipped>
>> To that end, I propose the following heirarchy:
>>
>> org.apache.avalon (stable subpackages and interfaces, etc.)
>>
>> org.apache.avalon.untested (packages and classes, etc under development)
>
>This seems the better solution from a marketing POV. Also, it
>removes some duplicity in naming (when accessing cvs, new users
>might think "framework? I thought Avalon was the framework". I
>just saw an existing user think that =).
>
>Perhaps it shouldn't be "untested" but "alpha" or
>"development". Doesn't matter that much. My +1.
I would prefer a whole other name/brand for that ...
org.apache.???.*
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Avalon Brand
Posted by Leo Simons <ma...@leosimons.com>.
<snipped>
> To that end, I propose the following heirarchy:
>
> org.apache.avalon (stable subpackages and interfaces, etc.)
>
> org.apache.avalon.untested (packages and classes, etc under development)
This seems the better solution from a marketing POV. Also, it
removes some duplicity in naming (when accessing cvs, new users
might think "framework? I thought Avalon was the framework". I
just saw an existing user think that =).
Perhaps it shouldn't be "untested" but "alpha" or
"development". Doesn't matter that much. My +1.
cheers!
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Avalon Brand
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> 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)
[ SNIP ]
> 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.
These are very good arguments, Steve. I am inclined to align with you on this
one. To that end, I propose the following heirarchy:
org.apache.avalon (stable subpackages and interfaces, etc.)
org.apache.avalon.untested (packages and classes, etc under development)
the heirarchy of the "untested" package should mirror how they will be merged
into the main package. There should be a package.html file in the root "untested"
directory that explains that once the utility/component/interface is ready for
prime-time, the package name will change. There should also be a disclaimer
for that code so that users will know it is a "use at your own risk" type of
thing.
The name "untested" does not imply instability (although that may very well
apply), but merely that we can't guarantee the usability or stability of
API of the code yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org