Thanks for the answer, Gregor. Some comments inline:
Gregor J. Rothfuss wrote: > > when we started this functionality, there was no workflow > engine around that specifically targeted the sane and common > 80% of the requirements. > so we wrote our own :) recently, some cocooners showed > interest in the code and making it into a block seemed the > right way to make more people aware of this code base. when > andreas designed this workflow code, he tried to seperate > generic workflow functionality from lenya-specific functionality. > > generic: > http://cocoon.apache.org/lenya/apidocs/org/apache/lenya/workfl > ow/package-summary.html > > lenya: > http://cocoon.apache.org/lenya/apidocs/org/apache/lenya/cms/wo > rkflow/package-summary.html > If this block stays in Cocoon you have to rename the packages to org.apache.cocoon.* > > > But I think we should sometime really start to discuss new blocks, > > otherwise we get burried under too many blocks noone maintains. > > In fact a block is a new subproject that perhaps should go through > > incubation etc. > > i think that would be overdoing things a bit. but i agree > that a way to deal with new blocks needs to be found. one > goal of lenya is to make more of its functionality into > blocks (revision control?, access control?, editor > integration? etc). whether those should be part of cocooon or > whether lenya should mirror the cocoon block architecture and > have its own is also an interesting question. in any event, > breaking it up in blocks makes lenya easier digestable for > interested parties :) > Yes, sure. I personally tend that it's better to first create the blocks at lenya and only if it really makes sense move it to Cocoon. We had the same problem years ago with general components that were moved from Cocoon to Avalon. Although this was from a theoretically POV the best thing to do, it created a mess and we still suffer a little bit from this move. I think (today), the code should stay where the community really is - even if some people say "Hey, cool, I'm interested" it doesn't mean that they will really participate later on. In any case, please ask the next time on the Cocoon dev list before adding a new block. > from what i understand, some issues with blocks won't be solved in the > 2.1 timeframe, and require 2.2. i wonder what easy steps > could be taken in 2.1? > I think you could use the same build system Cocoon is using with separate directories. Perhaps there is a better way :) Carsten
