Sorry, but I don't comment on this. Just one (final) question: are you -1 on the changes?
Carsten Sylvain Wallez wrote: > Carsten Ziegeler wrote: > >>Hmm, so why is ECM++ different from ECM (includes, JMX etc.)? With the >>same argument we could just use ECM with the container integrations and >>that's it. >> > > > Oh yes, sure! And why not going back to the Director interface of the > good old Cocoon 1.0 times? > > Seriously, ECM++ allowed us to add new features that we badly needed > such as xconf includes, and Spring bridge among others. > > >>Now, I'm only talking about constructor injection, so if you're using it >>you have a well defined life-cycle of that component as the constructor >>is called before everything else. Mixing constructor injection with >>other Avalon interfaces might cause confusion, yes. It's up to the >>component writer to decide this and we can come up with nice >>documentation telling everyone how to develop components. > > > Muhuhuhahahahaha! Nice documentation!!!! C'mon... > > >>I would suggest to either use constructor injectior or the Avalon interfaces >>but not both at the same time. >> > > > Great, I suggest the same by using the Spring bridge. > > >>However, there is one exception: the lifestyle. As we can't agree on making >>everything thread safe, I think the easiest way is to support ThreadSafe, >>Poolable etc. with constructor injection as well - with the default still >>being single threaded. >>With constructor injection we have a simple container which is able to serve >>POJOs while remaining compatible. And we are one step further in a smooth >>migration path. >> > > > Just use Spring: this is compatible, and allows to move away from Avalon > faster. > > >>Setter injection is a different thing - I personally don't want to add it as >>things imho get too complicated then (but if someone wants to do it, well, >>why not). >> >>And finally, Spring is cool and has nice features, but imho it has no >>clean separation between a component writer and a component user when it >>comes to configuration. In fact (as a teaser :) ), I'm thinking about >>writing a new core for Cocoon based on Spring which supports annotations >>and the avalon style configuration based on roles and xconf files. It's >>not that hard to do, but the question right now is if it's worth it. >>This could simply replace ECM++. But as we don't want to build on sand >>again, I think this is out of question anyway.... >> > > > Hmm... Is it April 1st already? > > >>Now, seriously, comming back to Gianugo's concern "adding features >>blindly not because of architectural/design issues but because it's >>tiresome to add 5 lines of code...": As I said, these changes make it >>imho easier to work with Cocoon and provide a required migration path. >> > > > I disagree: the migration path is to allow writing components *without > caring about Avalon*. Any mixed model is a complexification as it > requires to know both models and the interaction betwen them in mixed > model components. And a nice documentation is not the solution. > > >>Imho, the best way would be to think about a new architecture/design for >>a future Cocoon, build that and provide then migration paths. But the >>last months have shown that we have currently no common understanding of >>a future Cocoon - everyone has her own vision and plans. And as long as >>we are in this situation, we can imho only try to do simple steps >>forward and see where we will arrive. >> > > > Right. And the simplest and most consistent step to go forward is IMO to > just use what's already there, providing a nice bridge to a rock-solid > container used by thousands of people. > > Sylvain > -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
