Update. I've now implemented the HiveDoc generator as described in the previous message. The limitations are still:
- not all schemas are generated into HiveDoc - <conversion>s are displayed as their <rules> equivalent The first limitation could be solved by simply adding a getter to the RegistryAssembly. However, I think it might be cleaner if the Descriptor objects would retain the distinction between defining a schema and referencing an existing schema. I.e. the ConfigurationPointDescriptor could be changed from: public Schema getContributionsSchema(); public void setContributionsSchema(Schema schema); to: public Schema getSchema(); public void setSchema(Schema schema); public String getSchemaId(); public void setSchemaId(String schemaId); That's making the Descriptor classes more complex. But on the positive side I think it should then be possible to remove the dependency on RegistryAssembly in DescriptorParser (and thus also in ModuleDescriptorProvider). The RegistryAssembly is only used to resolve schema references (using SchemaInjector), which wouldn't be needed anymore. Thoughts on this? The second limitation can probably be addressed by inversing the dependency between ConversionDescriptor and ElementModelImpl... somehow :-) --knut On Wed, 13 Oct 2004 13:35:52 +0200, Knut Wannheden <[EMAIL PROTECTED]> wrote: > I've started implementing a HiveDoc generator which gets its input > from ModuleDescriptorProviders instead of reading the XML module > descriptors. This should allow HiveDoc being generated for module > descriptors defined in other formats. > > The strategy of the implementation is to assemble a single XML > document equivalent to that which the <createregistry> task creates > and then feed it to the existing XSLT to generate the HiveDoc. Maybe > this strategy should be changed in the future, but for now I think it > should be the easiest approach. > > This implementation requires many of the Descriptor classes to be > extended. Most obvious is a new "description" field. There are also a > few cases where the Descriptor classes don't provide a getter. All > this should be easy to fix. > > More problematic is: > > - <schema>s are not added to the Descriptor defining them. Instead > they're directly linked to the elements using them. But this leaves > out any unused schemas (e.g. "hivemind.lib.Pipeline"). > - A <conversion> element is "unwrapped" and cannot be distinguished > from its <rules> equivalent. > > Anyone got thoughts on this? > > --knut > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
