your wish is my command...I doubt this is more productive...
Irrespective of productivity - technical matters belong on the dev list. There were a couple of technical points I thought were incorrect and I wanted to raise those points with you.
... in particular - you said:
Component writers which follow this rule when writing Avalon components will create a component that is impossible to use in excalibur, cocoon, james, loom, plexus, phoenix, and other software projects that aim to support Avalon components.
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.
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.
and "sideways-incompatible".
:-)
Not sure what this is!
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 interfacesCheers, Stephen.
--
|---------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
