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?
modules/fop/src/org/apache/cocoon/serializer/FOPSerializer.java
modules/bla/src/org/apache/cocoon/components/bla/BLAComponent.java
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.
+1
> 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.
+1.
> 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
+1.
> f) Something I forgot
I saw that somebodies don't like the word 'module', perhaps 'extension'
is better?!
ext/fop/..
Stephan.5~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
