Re: Avalon Components (Re: Our site is too big)

Berin Loritsch wrote:

>>From: Paul Hammant [mailto:[email protected]]
>>
>>I am -100 on any CVS depot being called plainly 'avalon'.  
>>Why? Our users (and sister-project
>>developers) have been confused as hell for years on what 
>>Avalon is, and how it differentiates from
>>Framework and Phoenix.
>>
>>Pease...
>>
>>'Avalon' is just a site name now.
>>    
>>
>
>
>Paul.  We are narrowing what Avalon is.  In A5, there will be
>one client spec (Framework), and one Container.  There will
>also be the compliance test framework.  It won't be that hard
>to explain what Avalon is because it will be much simpler.
>
>I don't want to be in the place where we have 9 CVS repos at
>the end of the day.  The "phoenix"/"framework"/"Fortress"/etc.
>projects can have their own directory structure at the root
>of "avalon"--but please let's simplify.
>
>The trick is not to explain "Framework", "Excalibur", "Cornerstone"
>"Phoenix", "Site", "LogKit", "Apps", etc.  That is too much.
>Only explain that Avalon = Container + Components.
>
>The reason everyone is "confused as hell" is because we have
>so much going on.  Are we a tool supplier?  Are we a component
>provider?  Are we a set of containers?  Are we a logging utility
>supplier?
>
>One of the reasons we have gotten into trouble in the past is that
>we have every one of those things going on.  Avalon always has
>been and always will be centered on Component Oriented Programming,
>with a set of component and container contracts.  That is what
>Avalon is.  All the other stuff is cruft that muddied the waters.
>
>We added the Logging ToolKit because at the time there wasn't
>one available that support IOC.  Log4J is out, and JDK logging,
>and they both function the same way.  We have demonstrated that
>we can still provide loggers to the components, even if the
>underlying logging toolkit is not built that way.  In the end,
>we really don't need to host LogKit anymore.  Don't get me
>wrong, its a really nice logging toolkit, but now it only serves
>to dilute our "brand".
>
>We added our containers because components are fairly hard to use
>without them.  The only problem is that we have several different
>containers.  Again, we dilute our "brand" and our users are left
>guessing which one to use in their next project.  They all are
>built on certain presumptions.  Our new effort will try (to the
>best of its ability) to remove the need for many presumptions,
>and pull the best efforts from each of the container projects.
>
>We added utility code because we needed it for our projects.  The
>utility code became useful in its own right, and really didn't
>need Avalon to function.  Instead of placing those utilities in
>a project designed for them, we maintained them here.  Now, noone
>can tell what Excalibur is meant to be.
>
>The problem is that we have allowed ourselves to grow unchecked.
>We need to learn to look outside ourselves to see if someone
>else is solving problems we have in our core project which is
>the component/container relationship (ref implementation and
>client code).  if we develop the code and donate it to other
>projects that is fine.  We haven't diluted what makes Avalon
>what it is.
>
>People can understand that J2EE is a spec.  That spec has a
>reference implementation, and there are alternatives in the
>marketplace.  We need to position ourselves the same way with
>Avalon.  It makes it *really* easy to explain, and it stops
>the confusion for most people.
>  
>

+1
Well stated.
Cheers, Steve.

-- 

Stephen J. McConnell
mailto:[email protected]
http://www.osm.net