> 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. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
