Niclas Hedhman wrote:
Berin Loritsch wrote:
Niclas Hedhman wrote:
I think his point is that AF4 is both a component API as well as a Container API/Toolkit, and hence can not evolve at all.
My point is that historically AF4 (and prior) has always been just the framework. I have no problems with there being more to it than just framework--but there has been nothing I can see that has made it completely obvious that there is more.
Ok. I am trying to get to your main point...
It seems that there is a mis-understanding about AF4 and Avalon at large.
Prior to moving on to Avalon 5, there is Avalon Framework 4.x. which is contained (codebase wise) in avalon-framework-api-4.2.0.jar and avalon-framework-impl.4.2.0.jar
There is nothing in Avalon Framework(!) 4.2 stipulating that Avalon Meta 2.0 has to be supported.
Consider now, if AF4 is no longer considered a product (as is implied/stated/etc. by the current website). That means that I can't keep writing things that worked with AF4 because the "whole" of Avalon is the "reference implementation".
The "whole" of Avalon used to be AF4. We know this is insufficient, and don't have any problems with evolution. However, without AF4 being a product there is no place we can monitor (other than project descriptors and ibiblio) whether a new version has been released or not.
The perception (which is very real) is that you cannot be Avalon compliant with only AF4. So there is a huge question mark on both what it means to be Avalon compliant and when that was decided. You see, I just can't get a good picture on it.
That is why I keep advocating an AF4 product and a full definition of the Avalon platform being versioned. There is a big disconnect between what *used* to be the whole of Avalon (AF4) and what is now.
So, the only thing that we could continue to argue, is whether the Specification Declaration, that AF4.2 compatible containers MUST honor constructor injection of LifeCycle artifacts, is a reasonable evolution of the Avalon Framework or not.
I personally think that the change required in the container to evolve with this 'enhancement' is reasonable, and wouldn't raise much controversy, hence didn't react much when Stephen made the change.
The specification change really wasn't done in a way that would include other known ASF PMCs that work with and implement Avalon containers. So the Excalibur, Cocoon, and JAMES teams were left in the dark.
IOW, Everything up to Avalon 4.2 is just framework, and Avalon 4.3/5/X on includes framework, meta, and anything else I don't know about.
That is because there is no such thing as Avalon 4.2. There is an Avalon Framework 4.2, which doesn't require Avalon Meta or anything else (well it requires Avalon Logkit, but that will change later).
Is this a fair assessment of your concerns? And reasonable explaination that most of this flamefest is a misunderstanding?
I really don't care what the version is called, but I really think a unified "Avalon X" (fill in your own version number) for the current product will help--especially if Avalon Framework is not going to be a product.
--
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
