Il giorno 22/lug/04, alle 01:28, Stefano Mazzocchi ha scritto:
I say we write our stuff and be done with it once and forever.
I agree with you on one thing here. Depending on an external community for our foundations is a BIG risk. But I also want to balance risks against benefits. Spring is actively developed, well documented, widely used and thouroughly tested. Can you say the same of Kernel?
Now, I don't want this thread to escalate into a flame war of the kind "my container is better than yours". I actually want to point out what is the greatest benefit of Spring, in my mind. It is the fact that you can write components that don't depend on it and yet be managed by it. If you take a look at the small code sample that I wrote, you can easily see that most of what I did consisted in *removing* things. I removed all dependencies on Avalon, all of "extends AbstractLogEnabled implements Serviceable, Poolable, Recyclable, Whateverable". I removed looking up collaborators via a ServiceManager and instead injected them (like the XMLParser) via a setter. And I did *not* substitute them with Spring classes and interfaces.
So, what you're left with is a handful of beans that can be deployed in Spring but, if Peter wants to deploy them in Pico/Nanocontainer instead, fine. It should be easy. There are no dependencies on the container (see also point 1.4.1 of the manifesto).
(Note to self: rewrite unit tests so that they don't depend on BeanFactory).
To sum it up, Kernel is fine if it supports Type 2 and/or Type 3 Dependency Injection (that is constructor and/or setter based). It would better if it had more tests, but hey. And it is fine if it moves forward, but I won't be the one to move it, because I don't have neither the expertise nor the time needed to write a container. I use Spring in my daytime job for implementing applications, so my knowledge of it is growing, and I have some time to rewrite some Cocoon components to be compatible with a dependency-injection approach. If this means, as I hope, that they can be deployed in Spring, Pico/Nano, Hivemind or Kernel without changes, we can take some time to rehash all the alternatives and decide which one is best. In the meantime, let's fscking do something ;-).
Ugo
-- Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryptographic signature
