Noel J. Bergman wrote:
Basically it makes sense.3) The containers that are in the worksI'm still wondering if we really need different implementationsIt can be that we will eventually come to a single designPlease be specific about what you mean? As I see it, the current division of Avalon technologies makes sense to me: * Avalon Frameworks - these are the basic contracts that authors can expect to be guaranteed in all platforms, plus some simple utilities. * Avalon Excalibur - a major implementation of the the Frameworks. But not the only possible one. * Avalon Containers - container implementations. Guaranteed to support Avalon Frameworks, and typically written using Excalibur classes. * Avalon Cornerstone - common pluggable services. Best case says that they should run in any proper container. * Avalon Applications - a repository for "demo" applications that don't have their own place. Perhaps I am entirely wrong in my understanding of the conceptual division of things, so I am open to correction. I am admittedly a little loose in my definitions. The actual definition for Cornerstone, from the web site, ties it tightly to the Phoenix container. Doesn't such a division make sense? You have: interfaces, classes that implement those interfaces, containers that support pluggable components, a reusable library of utility components, and finally pluggable applications.
There are some issues though:
* Excalibur is not a major implementation of the the Framework. It contains utility stuff to create containers and some containers itself.
* Avalon Containers is not there, and containers have been growing in Excalibur.
* Avalon Cornerstone has components that cannot yet run in all containers. We should ensure that it can happen or that it's properly labeled where really impossible to make it cross-container.
Basically, expanding my original idea based on your mail:
1) Avalon becomes a single repository with framework and utilities. All utilities that are not Avalon-specific move to J-Commons- or Commons. This has already been started.
2) There is a place where to breed containers. Can be Avalon scratchpad or container scratchpad.
3) there is a place to keep containers. In my proposal it's in a ./containers subdir of the Avalon CVS. If the container becomes big enough, like Phoenix, it becomes an Avalon subproject in its own right.
4) Avalon Cornerstone and Avalon Applications are placed in a repository where multiple parties can collaborate. So it can be Apache Avalon Commons ot Apache Commons Avalon, but the concept remains.
Yes. The concept is correct, these things must compile not all together but following dependencies.If I wanted to write a new Avalon container for a real-time environment on a PDA, I ought to be dependent only upon the Avalon Frameworks. I could CHOOSE to use Excalibur, or not. In a best case scenario, if I implement my own container using nothing common EXCEPT for the Avalon Frameworks, I'd like to be able to use Avalon Cornerstone components without their having dependencies upon Excalibur classes; that may not be possible today - it is a normative notion. And third party should not be dependent upon anything not specified in Avalon Frameworks. This is mostly about clean separation, but there are also packaging issues.
Phoenix is released, proved and really stable. Think that someone has even gotten James working on a C# based JVMThat's true! LOL But how did you hear about it?
Blog -> Blog -> Blog...etc ;-)
Technically it seems sensible that there be one framework and more possible implementations. Community-wise, I'm not so sure.Perhaps. But I think that the dependencies should be kept clean to permit the option. Also, the cleaner the dependencies, the smaller the surface area, and the more flexibility to change in the future.
Yes, dependencies must remain clean.
Yes, as I tried to outline above the conceptual separation emains.if we cannot come to a single implementation, probably it's because we still don't know how to do it.Single implementation of WHAT, precisely? Frameworks? Absolutely. Necessary. By defintion, there must be only a single definition of Avalon Frameworks. Other than that, I'd prefer not to see any necessary dependencies imposed upon container authors or upon components. Let me point out that there are new notions coming within Java that effect certain patterns of use. Such things as JSR 166 will have an impact, and should. The same with java.nio. Loose coupling is good. Perhaps the coupling areas need to be better defined, and the loose coupling better enforced within the current code (perhaps even shifting things), but the basic concept of organizing around interfaces, classes, containers, and components seems sound to me. No?
And yes, we must better define the relations especially with regards to component protability.
Talking java-wise, we must define the interfaces that these levels use with the lower ones and stick to them.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
