Steven Noels wrote:
On 07 Apr 2004, at 16:05, Nicola Ken Barozzi wrote:
Steven Noels wrote:
On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:
The issue is not so technical as it's of indipendence from something that, in the good and the bad, has not helped Cocoon be built by Gump for ages now.
As much as I like "Gumpinal Correctness" for the sanity of us Cocoon committers, I'm not sure whether Gump has the goal of driving architectural decisions for the projects it is aggregating information from. It is a helper tool and should not decide for us, no?
Gump is deciding for us? Did I read "Gump wrote?" :-P
The fact is that a tool tells me that a project we depend upon does not get built regularly: this *does* impact on architectural decisions.
The reason of Excalibur not building might perhaps be because of its developers not caring enough about providing a strong contract to its users. We have an established codeset and user base which have habitually been adopting and using the Avalon *APIs* (I'm not referring to a particular container here) because of (a) they found out about them inside Cocoon, and were encouraged to use them for their own Cocoon components, and (b) maybe they even started to actually like them, and thus might expect us to provide identical services and interfaces in our own container - backed by a healthier community.
A big +1 here, also seconding Carsten. The Avalon *API* has led many people to COP, as this *API* provides simple means for a component to interact with its container. Sure, IOC type 2/3 make it more transparent, but IMO don't scale for large sets of components.
So although Cocoon will have a new container, it should not consider Avalon APIs as just a bunch of legacy interfaces that have to run in a sandbox. It's a slap in the face of many people that have invested time to build their application-logic components on top of an enabling infrastructure that was seamlessly integrated with Cocoon but could be used in other kind of apps, therefore allowing actual cross-application reuse of these components. Without this support, people are left alone without architectural guidance, and this will be a step back leading to unisolated spaghetti code.
So we can trash the ECM, we can change the configuration file format, but we *must* support (and not only as a legacy isolated sandbox) the Avalon framework APIs (a bunch of 1-method interfaces).
Cross-block classloading problems isn't an issue IMO, as it seems to me fairly easy to use dynamic proxies to translate calls to an interface to calls to the same interface in a different classloader.
My 1 euro. Yeah, a lot more than Steven ;-)
Add some USD to this. I'd like Cocoon to support Avalon Framework API also. I don't understand why Avalon components could not be wired to be exposed by block.
Vadim
