Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 59064 invoked by uid 500); 19 Nov 2001 13:39:10 -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 59053 invoked from network); 19 Nov 2001 13:39:09 -0000 Message-ID: <3BF90A06.20208@rabellino.it> Date: Mon, 19 Nov 2001 14:32:54 +0100 From: Gianugo Rabellino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011 X-Accept-Language: en-us MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [RT]: Restructuring the build system References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > The current situation is a little bit complicated. We have additional > components which are only included in the compilation if some > libraries are available during compilation. > In addition if these components are compilated there need to > be some entries either in the cocoon.xconf or in the sitemap. > This is partially done in the build, too. > > Now my problem is that if I look at the huge src directory, I > don't see which classes will be compilated, which are optional etc. > Even worse, there are classes in a package which are optional > and others in the same are not. Definitely the overall situation is a bit messy, yes. > Now this all could be made clearer with the following structure: > > src + core : The required classes which are always compiled > | > | > + opt - fop : FOP specific classes > - batik : The SVG stuff > - Xalan : Xalan specific implementations > etc. Sounds absolutely reasonable to me, as long as package names do not change (i.e. there is no org.apache.cocoon.optional package tree) > In addition to the src in each opt/{component} directory, > this directory could contain a cocoon.xconf and sitemap.xmap > fragment. The problem here is that you don't know where the fragments have to be inserted in the main config or sitemap file. How about inserting XUpdate fragments and let Lexus edit the files? AFAIK there should be no licensing problems in including Lexus in the Cocoon dist. > Now the build script knows the dependencies like if library > (=class) xyz is available, include directory /opt/xyz for > compilation and append the cocoon.xconf fragment and the > sitemap.xmap fragment to the configuration files. Again, the only problem that I see is that you can't just "append" the snippets and hope that they work... Ciao, -- Gianugo Rabellino --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org