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 Extending the build system for modules
Date Wed, 14 Aug 2002 14:28:17 GMT
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:cziegeler@s-und-n.de                  http://www.s-und-n.de
                    http://ziegeler.bei.t-online.de


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message