cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <>
Subject Re: Extending the build system for modules
Date Mon, 19 Aug 2002 07:14:26 GMT

On Wed, 14 Aug 2002, Carsten Ziegeler wrote:

> This is the proposed directory structure:
> /src/java   The core
>      webapp
> /modules/fop/src
>              samples
>              conf

Where should the Sitemap components go?


And which files should be in conf?

> 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.


> b) Libraries
> 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!

Will be difficult, I think.

> c) Dependency Checker
> Now, we need a dependency checker like Avalon Excalibur with the
> ability to specify inter-module dependencies and libraries dependencies.

Simply we could begin with dependency checker of Avalon.

> d) A deeper hierarchy for modules?
> or is only a plain hierarchy allowed?
> modules/fop
> modules/itext
> modules/session
> modules/authentication

+1, is easier to maintain.

> 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

I saw that somebodies don't like the word 'module', perhaps 'extension'
is better?!



To unsubscribe, e-mail:
For additional commands, email:

View raw message