"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: > > I don't buy this. > > The "component portability" argument is moot, it's a myth, you can't > even move components from one container to another in avalon and ECM > is deprecated, now even fortress is deprecated. > Sorry, but that's not 100% true. You can use your implementations from ECM in Fortress (and even in Merlin) without *any* changes to your java code. "Only" configuration is different. And sorry, it's not a myth - it's reality. In our company - and I know not only here - we are practicing this like three years now. Introduced because of Cocoon we are heavily based on Avalon. And the great thing is that these Avalon components work in Avalon containers, in Cocoon and in some other containers as well without any problems.
If we don't support them in the next versions, well, we not only have to rewrite them but we have to maintain different versions. We can't even use wrappers due to the class loading problems you mentioned. And that's very bad. > <SNIP/> > > > Ok, I think if we decide to use our own versions of the interfaces > > it will still be possible to do some hacky things and still provide > > compatilibity with the Avalon versions. > > There will be an avalon sandbox for legacy code. There is nothing > hacky in that. Sorry, I wasn't clear above: the sandbox is not hacky. What I meant is that *if* we decide to support the Avalon interfaces only in the sandbox, it should be possible to plugin a hacky solution that allows to use the avalon interfaces even in our blocks without any classloader problems. To be honest, I still don't buy the classloader problem theory. I'm just saying that we should try to support interfaces like Configurable etc. We have own classloaders for the blocks anyway, so it shouldn't be that hard, to solve the problem there. If classloading is the only reason against these interfaces than I think we can solve it. And the dependency is very minimal. It's just a dependency against the avalon framework api version 4.1.5 - a released version. There is no need in following the development of Avalon. Carsten
