Anton Tagunov wrote:
Hello Stephen!
Hi Anton:
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.
Why is fortress-meta dependent on Fortress? Can they be more cleanly seperated? Can Fortress meta be migrated to the meta package?
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?)
Meta info (details about a component type) should be very closely aligned with the framework. Tools to produce this meta-info should be totally container independent. I think that this sort of content should eventually be colocated with the framework - e.g.
avalon
framework
meta
toolsCurrently the meta-info models are different across all containers. Fortress uses text file called <classname>.meta into which the component type name is written along with services that the component provides. Dependencies are stored in a seperate <classname>.deps. Entries in both files a delimited by line breaks. Phoenix provides the <classname>.xinfo file which is XML based and provides additional information coverning management access points and configuration schemas. The meta used in Merlin provides support for serialized and XML descriptors under the <classname>.xserial and <classname>.xinfo. The meta package contains additional information the covers context criteria (enabling things like the declaration of the Phoenix context casting assumptions and context entry assumptions), declaration of the logging categories used by a component, and the ability to associate attributes to features of the component type.
Relative to the existing approaches the meta package comes closest to meeting the full suite of meta-info modelling requirements, although this still needs to be enhanced to capture JMX management access points and configuration schema references.
Under the meta package the existing tools provide support for the construction of a meta-info object model based on javadoc tags. The meta-info model can then be externalized into either xml or serialized form (and in the future - any other persistent storage model we want to come up with).
Meta data (details about deployment of a component or set of components) are much more closely aligned with a particular container. For example, Phoenix meta-data includes the assembly.xml and configuration.xml files, Merlin uses block.xml in conjunction with .xprofile directives. Fortress has it role files. In each case the meta-data reflects the logic and feature set of the containment environment. As such, this isn't a something we should be trying to standardize today (it much more interesting to get meta-info sorted out).
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?
A common meta-info model that is container independent and addresses the complete set of requirements across the three avalon containers is all that is needed. Any tools that are container specific should remain with the container that they are specific to.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
