cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: cvs commit: cocoon-2.1/src/blocks/workflow/java/org/apache/lenya/xml DocumentHelper.java
Date Mon, 01 Mar 2004 09:48:38 GMT
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


Mime
View raw message