Hi Team,
we recently had our thread about Cocoon organization etc. and
it's now time to recapitulate the results.
One main result is to split the core from optional things that
we from now on call modules (and not blocks!).
This is the proposed directory structure:
/src/java The core
webapp
/modules/fop/src
samples
conf
A build results in a separate jar file for the src and if
the webapp target is choosen the configuration is merged
into the webapp and if samples are choosen as well, the
samples are copied to the webapp/samples directory.
So, there remain some open problems:
a) Documentation
Where does the docs belong to? I think they should go into
the modules directory, so for examples /modules/fop/xdocs.
The build script can then automatically combine all these xdocs
sections during build, so it's in the end no difference if the
docs are residing in the module directory or not.
b) Libraries
Where are libraries for the optional components stored? A natural
fit would be directly in the modules, like /modules/fop/lib.
But I think this is not a good idea, because it could be that
two different modules require the same optional library. And
storing the jar twice is no solution.
So, here is my suggestion: Everything stays at it is. All
jars go either into lib/core or lib/optional (or lib/local).
The optional modules check these places for availability of
libraries.
And now the fun part: The build system checks which optional
libraries are really used and only copies those to the webapp!
Why not simply copying all optional jars? For example, imagine
the fop.jar in the lib/optional directory (which is there by
default) and you built Cocoon without fop module, then you don't
want the fop.jar in your app.
I think this checking can be done by the...
c) Dependency Checker
Now, we need a dependency checker like Avalon Excalibur with the
ability to specify inter-module dependencies and libraries dependencies.
If we have this dependency information it should be easy to implement
the above topic b). (Collection which optional modules where build
and which libraries they require and then copying only these libs).
Or a simpler solution is that the optional libraries are not copied
at all by the main (=core) build script but by the module build scripts.
Then automatically only the required ones are copied.
d) A deeper hierarchy for modules?
Do we want this? For example grouping similar modules, like
modules/pdf/fop
pdf/itext
webapps/session
webapps/authentication
or is only a plain hierarchy allowed?
modules/fop
modules/itext
modules/session
modules/authentication
e) A selection system
were a user can specify which modules she wants (like an interactive
build) - the default should be all modules (which can be built).
This could simply be done by an ant properties file, like
modules.pdf.fop=no
modules.pdf.itext=yes
f) Something I forgot
Comments?
Carsten
Carsten Ziegeler Chief Architect Open Source Group, S&N AG
------------------------------------------------------------------
Cocoon Consulting, Training and Projects
------------------------------------------------------------------
mailto:[EMAIL PROTECTED] http://www.s-und-n.de
http://ziegeler.bei.t-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
