Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E67784C.3020809@hisitech.com>
Date: Thu, 06 Mar 2003 17:33:16 +0100
From: Santiago Gala <sgala@hisitech.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: refering to:
 http://wiki.cocoondev.org/Wiki.jsp?page=CocoonUpgrade
References: <20030305161530.GA19770@kompuart.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Leszek Gawron wrote:
> I think it would be nice if cocoon.xconf could be docomposed into several
> files. why ? Now when changin cocoon version I have to:
> 0. build appropriate version (now it's easy as no javadocs/examples/docs are
> included)
> 1. edit web.xml file to include database driver class loading (obviously that
> connot be moved elsewhere)
> 2. edit cocoon.xconf:
> 	- remove standard datasource (that exists there even if you do not include
> 	  samples, but include database block)
> 	- add my own datasources
> 	- add my own logicsheets
> 	- add my custom components (I do not have ones but surely will have in the
> 	  future)
> 3. customize logkit (add my own categories so I can search entries faster)
> 4. Default sitemap automounts subsitemaps now so it's enough just to copy the
> files
> 
> What's wrong with that ? if you have one additional datasource and one
> logicsheet- no problem, but when changing versions in more complicated
> environment it may drive you nuts.
> 
> The solution would be to allow users create their own cocoon.xconf files
> (residing in the same place as sub-sitemap.xmap that defines local custom
> enhancements). The file could be loaded and components initialized the first
> time users accesses a subsitemap. Is it at all posible ? Same for logkit?


Other possibility would be that you write a patch (diff -u WRT a clean 
config tree) and store it, to be applied when upgrading, and checked 
manually (always needed, as configs tend to have new/changed semantics 
every now and then), even if the patch succeeds.

Just my 2 cents.

Regards,
      Santiago

> 	ouzo