> Nico Klasensn wrote: > > 1 adding only this to the target means duplicating config > files in the > > distribution, isn't it? > > Yes, unless we exclude the config dir in the ditribution, > which is likely not very helpful.
Duplicating or hiding as much as possible is helpful? The strength of MMBase is its dynamic and flexible way of doing things. The config files are a reflection of this strength. I don't understand why it should be moved to an non-intuitive place. > > I prefer runtime crashing above runtime assuming. A seperate jar or > > only the very unlikely modified resources would have my +1. > > We could filter certain resources, but which would these be? > And how are we going to filter the right configs? > An alternate possibility is to move the 'core' config (core > builders, stoarage ersoyrces, dtds, basic default > configuration xmls) into the src tree, and instead of copying > the config to the jar, copy the contents of org.mmbase.config > to the config dir. Applications - include only the basics.xml Builders - include core builders Databases (storage) - include. Something is wrong when these have to be changed Dtd - include. Functions - include. Log - don't include. The default one is definitely not production ready Modules - don't include. Not all modules are used always and the others will be modified. Security - don;t include. Very likely that you want another one. Utils - include. Most utils won't be changed Xslt - ? accounts.properties - Definitely not caches.xml - include. Ok for most sites. magic.xml - include. With a listing like this I don't see a real advantage to include the full config dir in the main jar. Having the possibility to store the config files on multiple places doesn't mean the distro has to do it. Nico _______________________________________________ Developers mailing list [EMAIL PROTECTED] http://lists.mmbase.org/mailman/listinfo/developers
