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]