Re: [Developers] VOTE: Optimization STEP 9: adapting build.xml forconfiguration
They are (or should be) all available on http://www.mmbase.org/dtd. Otherwise a find . -name *.dtd in the src dir would quickly find it. neither are good options http://www.mmbase.org/dtd don't always match you mmbase version and if you USE mmbase your don't have the source available ___ Developers mailing list [EMAIL PROTECTED] http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] VOTE: Optimization STEP 9: adapting build.xml forconfiguration
Kees Jongenburger wrote: They are (or should be) all available on http://www.mmbase.org/dtd. Otherwise a find . -name *.dtd in the src dir would quickly find it. neither are good options http://www.mmbase.org/dtd don't always match you mmbase version It should, because the version of the DTD is (should be) increased if it is changed. Therefore the same DTD's are present more than once there. and if you USE mmbase your don't have the source available No, and you probably don't want a DTD either. You want documentation then. Michiel -- Michiel Meeuwissen mihxil' Mediacentrum 140 H'sum[] () +31 (0)35 6772979 nl_NL eo_XX en_US ___ Developers mailing list [EMAIL PROTECTED] http://lists.mmbase.org/mailman/listinfo/developers
RE: [Developers] VOTE: Optimization STEP 9: adapting build.xml forconfiguration
[X] -1 (NO), because : 1 adding only this to the target means duplicating config files in the distribution, isn't it? And why do we then still need the first copy-tag? 2 Adding all config files to the main jar would mean that MMBase will always fallback to default config files when they are not overridden. This can lead to very confusing behaviour. If you forget to configure (override something) then MMBase could do something completely different without telling/complaining. I prefer runtime crashing above runtime assuming. A seperate jar or only the very unlikely modified resources would have my +1. Nico ___ Developers mailing list [EMAIL PROTECTED] http://lists.mmbase.org/mailman/listinfo/developers
Re: [Developers] VOTE: Optimization STEP 9: adapting build.xml forconfiguration
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. And why do we then still need the first copy-tag? The first copy tag copies resources from the src tree. 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. -- Pierre van Rooden Mediapark, C 107 tel. +31 (0)35 6772815 Some Drink at the Fountain of Knowledge. Others Just Gurgle. ___ Developers mailing list [EMAIL PROTECTED] http://lists.mmbase.org/mailman/listinfo/developers
