Hello, as a relatively new user of HiveMind, I thought I would share my impressions/thoughts after applying it on a medium sized project. Please take this as constructive criticsm. Some of the issues are just part of the learning curve, some of them are due to the fact that it's still in it's early stages, and some of them I feel are issues with general approach taken.
HiveMind seems to be a mixture of an IoC/dependency management container and a a POJO/XML data binding framework, with a bit of xml-based scripting thrown in. No real issues with the IoC part - the concept is well estabilished and I find it natural to think in these terms. The headaches start with the OO/XML binding framework. For simple dependencies, it's easy enough to set things up. The first dubious point is the distinction between services and configurations. IMHO this distinction really doesn't help at all: it doesn't add any value to introduce two concepts, where one would be sufficient. Both services and configurations are objects that get initialized via xml declarations and have dependencies. It's not clear to me, at what point a certain dependency should be a service or a config. A configuration seems to be necessary when I want to create a reasonable XML syntax (schema) for initializing objects of this kind later on (and even though you can make the xml for configurations look reasonable, they remain Lists which is an artifact that impacts the domain object model). I feel the XML configurations lack the simplicity and consistency that's crucial for developers to effectively use the framework. What would have been a few simple lines of java code (not to mention a scripting language) become tedious pages of XML. I feel HiveMind reinvents the XML/OO binding wheel once again, estabilishes it's own schema language, variable substitutions etc. IMHO this is a critical issue. It would be better to promote the Java based dependency management APIs and expose them to direct manipulation, scripting languages and your favorite java/xml binding framework, rather than trying to reinvent this. Madness lies this way, and you can already see the numerous dead corpses on the roadside :) - think Jelly, the numerous wretched xml/oo mappers that would be best to forget, etc.. Registry initialization should be more flexible and support different deployment scenarios that are not one jar/one hivemodule. A common real-world example is environment-specific configurations. The approach I implemented was a custom registry initialization sequence, that after addDefaultModuleDescriptorProvider(), finds a "hivemind.registry" in the classpath, and loads the further hivemodules listed there (these are simple resource URIs that look like classpath:/com/example/foo.xml or file:/foo/myproject/config.xml), then loads further config resources that were programmatically added (eg. from a testcase setUp()). I feel this should be part of the framework - if you're interested I can send the corresponding code. Documentation needs to be more example-based (at the least give more guidance on where in the reference to look for things). It's a real headscratcher to figure out some of the functionality that is clearly there (jndi, ejb remoting, etc). Guidelines/best practices should be focused on. Again, don't take the above as flamebait, but as a call for discussion and improvements :) I think for HiveMind to succeed, it needs to provide a very solid and simple core, and focus on it's essential strenghts. Best regards, Viktor --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
