I am more concerned with all the other blocks than the ones you
mentioned, as many blocks contain their own transformers, serializers,
etc. and use the same namespace. So here are a couple of thoughts.
1. Right now users can find documentation on the sitemap components they
want to use just by looking at the javadoc. Since, in 2.1, Cocoon is one
monolothic entity it is really easy to find the documentation on all the
transformers (or actions, matchers, etc) at once and then find the one
that does what you want. I know because I've done this many times.
2. It seems to me that the "proper" way to do segmentation would be to
require a package naming convention of o.a.c.blockname.other.stuff.
This lets you know that a transformer is part of a specific block so you
know where to find it. Now the major problem with this is knowing that
the transformer exists in the first place. Perhaps something like
Maven's list of plugins at http://maven.apache.org/plugins/index.html
could be created to describe all the blocks, but we'd then also need a
xref for each component type listing its name and the block it is in.
So, in short, I think your proposal is a good idea if done across the
board as long as we update the documentation at the same time.
Ralph
Daniel Fagerstrom wrote:
We need to find a solution for this and also decide what conventions
we should have for package naming and what we use packages for. OSGi
(and Java in general AFAIU) is based on the concept that a package
contains a number of classes that works closely together to provide
some well defined functionality. In Cocoon we sometimes use packages
in this way, but also quite often based on some kind of similarity,
e.g. o.a.c.transformation. The later use of packages, doesn't work
well with modularization. I recommend you to read Peter Krien's blog
about why packages are the right level of modularization:
http://www.aqute.biz/2006/04/let-us-not-make-same-mistake.html.
WDYT?
/Daniel
