Hello Stephen! SM> Why does the excalibur datasource build have a dependency SM> on the fortress container?
PR> Probably for fortress' meta-info generation. SM> I recommend we remove the fortress dependency and include any meta info SM> needed by fortress as a static artifact in CVS. This is the same SM> approach that is used in the cornerstone components - i.e. no container SM> dependencies. SM> What do you think? This already happens with SourceResolver since the dependency graph is datasource - > fortress - > sourceresolver See how it works there. (It's mainly in fotress-meta.xml file). If sourceresolver finds fortress-tools.jar it generates the metainfo, if it does not it uses the cvs-supplied one. Also at every build if fortress-tools.jar is found the files under src/fortress-meta are regenerated. There have been talks on how to do this. One idea was to have a separate excalibur sub-project to concentrate meta tools, but it has yet to shape out probably (if it will ever be created). The code in sourceresolver that does this fortress-meta fuss is mine and Berin has characterized it as "looking more like a hack". However we agreed that it was the best that could be done. (The matter was holding fortress release then.) Whether we want this "hack" to be copied to * datasource * monitor * event (all these also depend on fortress-meta.jar) or not is a question. It can be done, but this will probably mean that the fortress-meta.xml file will be cloned 4 times. Brrr... Maybe yet start a meta-tools project somewhere. (avalon-excalibur? avalon/tools?) We could move fortress-meta.xml file there. A similar file can be written for generating Phoenix meta. Okay it is not a full blown meta-generationg subproject, but it will be better then nothing, will it? -Anton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]