Ugo Cei wrote:
The interfaces that are in Butterfly are a verbatim copy (apart maybe from some minor changes, some time has passed and I don't remember all the details) of the Excalibur ones.
Of course, the package names have changed (and the o.a.butterfly will have to be changed to o.a.cocoon if they ever make it into the Cocoon core), but are you suggesting that we shoud keep o.a.excalibur.source.Source and so on?
Of course! We *must* keep all Avalon / Excalibur interfaces which are currently employed in our code base. But implementation is a different story.
Don't know :) I'm just concerned about compatibility and about the learning curve. Today people are used to the excalibur source handling - which takes a little bit of time to learn. Introducing a new source handling - even if only the interfaces are different - increases this learning curve as they have to get used to new things.
Hmmm, OK, how about:
package org.apache.excalibur.source;
public interface Source extends org.apache.cocoon.source.Source {} ?
You mean this as a compatibility layer, right? So, new code would use the o.a.c.s.Source and old code can still use the o.a.e.s.Source?
Hmm, I actually don't know what's best. What do others think?
The best plan IMHO would be:
1. Remove ECM - implementation of Avalon container. Keep re-usable components code (XSLT, Source, Store, etc).
2. Drop in the container which replaces it.
3. Write bridge code between container in (2) and (1).
4. Test.
5. Release Cocoon 2.3.
6. Continue with usual Cocoon development: improvements, refactorings, as you see fit: rewrite source resolving or sitemap processor or whatever you want if you have time for it.
For a useful example of 6, Store implementation should plug in into Java 1.5 management API instead of having background checker thread.
Vadim
