The Dentaku Metadata Service is a component that can read UML models into JMI, decorate the results with convenince routines, and provide the results to your client. This component was previously a direct part of the generators themselves, but the need was apparent that this functionality should be available to application clients as well.

There is very little documentation on this other than the example code, the [Gentaku] generator code, and the metadata code itself. The generator code provides the most extensive use of the component, and probably provides the best resource for it's use.

Since XDoclet2 is the foundation for Gentaku, it made sense to see if we could enhance this code to generate code that would feed existing XDoclet2 templates directly. Without this, generator templates that wish to take advantage of XDoclet2 are required to write the XDoclet tags into the template so that the information is available in the source. This takes time and is prone to errors, so if we could trigger the XDoclet2 plugins directly, we would not have to trigger the templates as such.

Underneath XDoclet2 is a project called Generama. Gentaku and XDoclet2 are both Generama clients, but XDoclet2 was the first client. The metadata that is fed into XDoclet2 is done so with a component in the XDoclet project called QDoxMetadataProvider. The MetadataProvider interface that it implements returns an opaque Object from the getMetadata() method, and in the case of XDoclet, it returns a Collection of QDox JavaSource objects. The XDoclet2 templates proceed to use the QDox Model interfaces to recover metadata about the project being built for. At last count, there are a dozen plugins and significant amounts of test code that rely on the QDox model interfaces. While it's been said that the QDox model is not meant to be an interface standard, it has by nature of this use, and it seems far to late to change that now.

So we are left with the task of mapping the JMI source of our UML model to QDox interfaces. This is not difficult, the two models have reasonably similar semantics, and we are lucky that JMI is more granular than QDox, making the QDox facade a comination of calls on the JMI source. But the QDox interfaces are not extracted, and that is the first order of business. That's been completed, here is a UML graph of what has been done:

The only significant changes outside the model were to test classes that were directly instantiating QDox model objects as a part of their test code. This shouldn't happen in most projects, but if it does, it simply requires the creation of the appropriate implementation of the interface instead of what has become an interface itself.