Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
<snip/>
Add your reasons.
Since Avalon came to life and I came to love it, I've had long fights with some of my colleagues at work to convince them to use it, in order to have robust architectures. Their argument was that they didn't want to use Avalon because of its viral nature: once you start using it, you have to use it everywhere and your code no more can be used outside an Avalon container. Although I wanted to promote Avalon as a way to have an homogeneous way to hold the various parts of a project, I also understood their arguments.
It hurts when loved ones fails us ;)
State of the art has evolved, and strangely we can consider that the writing style that DI brings us is in some ways going back at a time where COP did not existed, where people were writing spaghetti plates dependencies. DI simply allows us to have spaghetti plugs in our classes and it actually wires the spaghetti plate, without enforcing a rigid structure where you must fit or go away. In some way, DI allows to manage the chaos.
Now I understand all your concerns about the revolution this may lead to, and I recognize I may be a bit over-enthusiastic. If you read the archives (e.g. [1]), I wasn't that happy at first.
My view seem quite close to your in [1], it will be interesting to see if I also will see the light within the next few mounths ;)
But my mind evolved as I was looking at Spring and all the cool features it provides. Sure, these features may only be really useful for business logic, but why not also for Cocoon components?
Yes, it would be interesting to find out. But I really think we can live without yet another "next generation" fork. If it could be found out in an evolutionaty way, I'm all for it.
This is still theoretical, but I have the feeling we can make this revolution in a smooth way, by facading a Spring container with an Avalon container implementation. I'll spend some times on this in the coming weeks, and we'll see what comes out of it.
Sounds like a good plan to me.
<snip/>
The death of Avalon doesn't force us to do anything in the short term. Actually it takes away part of our previous problems, no one is going to do anything hostile about the API anymore. And if we feel that we must develop it we can steal it without upsetting anybody.
You're totally right. The death of Avalon makes us free to do whatever we want with these APIs. Now the question is: do we want to live with a dead thing when we have more lively alternatives in front of us?
Decreasing the Avalon dependency would certainly be a good thing. I just wanted to point out that we don't have to panic.
I think a reasonable sequence of steps would be:
1. Make it possible to use components that are managed by an external container from within Cocoon components. This could probably be implemented by letting the Cocoon component manager call an external component manager for components that it does not handle it self. The coupling to external component managers could maybe even be configurable, to make the system future proof.
Wouldn't this take a way the dependence on Avalon interfaces for most user needs. If you are going to write new sitemap components you will still need to use Avalon interfaces. But IMHO, the need of writing stemap components is much reduced today compared with the situation before. You can do most of your integration work using flowscripts. If we could find a good and common way to write new template languages (a Jelly generator/transformer maybe?) we could reduce the need for writing new sitemap components even further. I guess
2. Make it possible
Also, from a marketing point of view, how will you explain to a customer that the foundations Cocoon components are built upon are a project that has been closed?
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108964393220564&w=2
