Was: Re: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./
pom.xml src/ src/main/ src/test/
Carsten Ziegeler wrote:
Daniel Fagerstrom schrieb:
Jorg Heymans skrev:
Giacomo Pati wrote:
...
Each block should have the same groupId yes. Should we make it
o.a.c.blocks ? (in analogy with [1])
Everything will be a block, the core included, in analogy with [2]. So
it would be redundant to introduce an extra level in the groupId.
Hmm, don't we need some "bootstrapping", for example the cocoon servlet
or the cli main class etc? I think these are not really blocks. Even if
they are from an implementation pov, they are not from a functionality
pov. So personally, I would distinguish between blocks and
"bootstrapping" which could be core.
One of the goals from the NG discussions during the end of the last year
was to make Cocoon less monolithic, and make it easier to reuse parts of it.
At the top layer in an layered Cocoon architecture I envision that we
have "controllers" (that implement Servlet). The controller chain for
large Cocoon systems would be:
BlocksManager -> BlockManager -> [SitemapServlet | FlowscriptServlet |
JavaFlowServlet | ... ]
In a small application with less need for modularization the controller
chain might be just:
FlowscriptServlet
If we want the different controllers to be reusable it makes less sense
to consider one of them a bootstrap layer.
The blocks framework is under refactoring to implement this vision.
--- o0o ---
Until things has settled a little bit more I suggest that we keep the
current flat layout with o.a.c as GroupId.
I also think that GroupId should reflect community structure rather than
function. If we start to grow as a community and get clear sub
communities that work on disjunct set of artifacts, it would make sense
to have a more fine grained GroupId structure.
/Daniel
