Stephen McConnell wrote:
This is no different to the introduction of the Serviceable interface and ServiceManager. Container implementation that existed prior to enhancement to framework are presented with a choice - upgrade or restrict support to Composable. This is no different - container implementations can choose to support injection or alternatively test for a null constructor.
Which was also not as smooth as it should have been.
As for the list - I just want to clarify that James is not impacted by this in any way at all. Phoenix is not an issue - it will continue to support 4.1.X. I'm not involved with Cocoon but it was my understanding that they were looking at a Cocoon specific container and more recently some discussions about Fortress. As for Excalibur, Loom and Plexus - the addition of support for constructor injection, along with support for standard context entries, standard meta-info descriptors and packaging specifications, etc. remains with the respective development communities.
As such, it is highly backwards-incompatible
There is absolutely no backward incompatibility.
Constructor injection is not compatible with the requirement (that used to be stated in the docs) that all components must have a public no-argument constructor. In fact it controdicts it completely.
It effectively destroys the common denominator between these projects for no good reason.
The good reasons:
1. improved compile time checking 2. reduced memory consumption 3. significant reduction of lines of code 4. elimination of potential errors by component authors related to sequential artifact delivery 5. reduced dependency on framework interfaces
Look, the primary concern here is not the 5 reasons you cited here. The primary concern is that the 4.x version of Avalon (i.e. framework alone) is gone. You are working on Avalon 5 but calling it Avalon 4.x--this is a huge difference.
We need to nail down what constitutes Avalon 4.x. Up till Merlin became
a prominent project within Avalon, 4.x was identified by Framework--alone. Whether you agree with that or not is up to you, those are the facts. Now we have the Excalibur project that needs to produce an Avalon 4.x compliant component container. The problem is
that now it is a moving target that can't be nailed down. We need to
nail it down because it is affecting the work being done in other Apache
chartered projects. The best way to nail it down without creating undue
stress is to keep Avalon 4.x remain the framework alone and call the current stack of contracts Avalon 5.
--
"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]
