Carsten Ziegeler pisze: > Yes, that's true. Now, at some point we have to break compatibility to > get a cleaner architecture and > an even better way of doing things. Perhaps removing sub sitemaps is one > of these things, perhaps not.
Before we start to think about migration path and embedding 2.1 as "emergency help" for existing users I really think we should agree what we are going to deprecate and remove in the future and most importantly how we envision future Cocoon's architecture so there will be no "perhaps yes, perhaps no" doubts any more. > But on the other hand there are many applications out there using this > stuff and they don't want to migrate. There is no real benefit for them. > But there is benefit for them using latest and greatest Cocoon for now > stuff. And this is very I think embedding 2.1 in 2.2 might make sense. > It allows people to run their old applications without modifications > while at the same time they can start new apps with 2.2. If people don't want to migrate I would tell them to stick to 2.1, it's stable and final release of 2.2 won't make 2.1 unusable. > As Cocoon 2.2 uses Spring as the container and as the Cocoon beans are > added to the Spring root container, these things are available in 2.1 > through Spring as well. So people are able to call 2.2 stuff from within > 2.1. It might be a thin bridge in terms of possibilities but I think > going this way makes things easier. Carsten, haven't you forgotten that in 2.2 all components (even Avalon-based) are managed by Spring? I mention this because I can easily imagine clashes between the same components defined both in 2.1 and 2.2. If you want to make anything usable you must assure collaboration in both ways between 2.1 and 2.2 so all components must be shared and clashes are unavoidable IMHO. Really, the more I think about this I idea the more obstacles I see but maybe I'm lacking something. Anyway, I think that the most important point is made earlier that we must establish goals we want to achieve before we start to think about implementation. Thinking more about incompatibilities between cocoon: and servlet: protocols I'm getting an impressions that they are not such fundamentally different when it comes to their usage schemes. Of course they differ in many details but as Reinhard properly characterized differences comes from the fact that servlet: protocol just tries to avoid side-effects cocoon: protocol allows. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
