Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 88441 invoked by uid 500); 19 Aug 2002 07:14:21 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 88430 invoked from network); 19 Aug 2002 07:14:20 -0000 X-Authentication-Warning: vern.chem.tu-berlin.de: stephan owned process doing -bs Date: Mon, 19 Aug 2002 09:14:26 +0200 (CEST) From: Stephan Michels X-X-Sender: stephan@vern.chem.tu-berlin.de To: Cocoon-Dev Subject: Re: Extending the build system for modules In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org