Hi all, I still have quite a few changes in the pipeline I've been working on but haven't committed as no definitive solutions have crystalized in the discussions on the mailing list. I'd again like to bring it all up for discussion as we were aiming for a soonish 1.1 release ;-)
1. Version matching for module dependencies. It's now quite a while ago I added support for explicit dependencies between modules. Back then we discussed various version matching types which we could implement. So far HiveMind only supports "perfect" matches or "any" matches (if no version is specified on the dependent's side). We couldn't all agree on how the user should specify the matching type so I just left it at that. How should we go forward with this? (I'd still favor an approach with an additional optional "match" attribute :-) ... Just remembered that HiveDoc currently doesn't account for dependencies yet. 2. Visitor pattern for Descriptors. I've implemented this visitor pattern as I previously described it on the mailing list. I just thought it was cleaner with a general purpose visitor than an explicit XMLWriter. Do you think this is worthwile? 3. Delegate schema linking to RegistryBuilder. Currently it's the DescriptorParser which links the Schema objects to the referencing ConfigurationPointDescriptors and ServicePointDescriptors. IMHO it would be cleaner to let the RegistryBuilder handle this linking. This would require additional attributes on the Descriptors for the case when a schema is being referenced by ID and an attribute on the ModuleDescriptor for the schemas declared at the top level. The DescriptorParser's (and thus ModuleDescriptorProvider's) dependency on RegistryAssembly could then be dropped. 4. Support for Groovy module descriptors. I have implemented a GroovyModuleDescriptorProvider which I thought we could add to hivemind-lib. This would although add a dependency on a groovy.jar. Further the implementation requires that the DescriptorParser can be used as a normal XML ContentHandler. This can be accomplished by adding alternative initialize() and a getModuleDescriptor() methods. But splitting it into two classes somehow would probably be cleaner. Cheers, --knut --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
