HiveMind is being very, very actively developed. I've been putting a lot of info onto my blog: http://www.freeroller.net/page/hlship/Weblog
I realize that some aspects of Avalon and HiveMind overlap.
I think our goals are a bit different. HiveMind is intended to form a lower-layer; Avalon is a services container, HiveMind is a services and configuration microkernel. The majority of HiveMind is related to building and contributing configuration elements. HiveMind expressly does not have the same kind of Inversion of Control that Avalon has; IoC or not is left to the developer. Avalon (or at least the Avalon containers I researched) require more explicit connection of services. I did not see anything akin to an Eclipse plugin model for handling configuration ... that's HiveMind's strong suit ... HiveMind's "assembly" stage occurs dynamically, at runtime.
:) I understand completely where you are comming from. There are now three different container implementations in Avalon land now. Fortress and Phoenix are the released containers, and Merlin is still under development although it is fully functional and rather featureful. Groking what's what can be a bit daunting. We are in the process of identifying the most flexible code base and evolving into one code base which will help lessen the load to understand everything.
That said, Avalon does firmly entrench the IoC pattern--which has paid for itself in spades on many projects--but enough of that here. Both Phoenix and Merlin have a MicroKernel, and Merlin has runtime assembly features. So there is more overlap than you might of origionally thought.
However, more on that later.
I know it sounds like "not invented here" syndrome, but I had a short window of opportunity to put something together, keep it open-source, but use it in a very large scale project at work. In this situation, it was faster, easier and politcally safer for me to build it myself than it would be to take the time to fully grok and adapt Avalon. Additionally, a key requirement for me is line precise error reporting [*]; this is a major amount of work to graft into an existing code base.
Also quite understandable. As to "politically safer", the politicing in Avalon land has gone down quite considerably in the last month or so. It is a much nicer place to be now. That said, at the time you started working on HiveMind things were probably in turmoil in Avalon--so I can understand your hesitance at that time.
Ultimately, I see HiveMind fitting in below Avalon; perhaps it may be adopted as the way in which the Avalon container is configured, rather than the way services hosted within the Avalon container are configured.
I am very interested in seeing how HiveMind and Avalon can cooperate. While HiveMind has a set of features and other goodies, there is some overlap. That overlap does not mean that one must survive and the other die, but it means that we might be able to cooperate on how to define different features/aspects that will work in both environments. I want to see where the two projects can cooperate, sharing experience and such. By helping each other understand the differences and similarities we can probably establish a good relationship. It will help the Avalon team understand where they have failed to meet your requirements, and it will help you understand the challenges we have already faced and how we overcame them.
[*] In Tapestry, and now in HiveMind, XML configuration files are read and converted into "descriptor" objects, which are then used to create runtime objects. In Tapestry, it's component specifications used to create components and pages and such. In HiveMind it is more open-ended. The line precise bit is: when the XML files are read, the exact location (file, line and column) for each descriptor object is recorded as a property of the object. When the descriptor object is used
Hmm. Have you seen my BXML project at d-haven? http://d-haven.org/bxml It will allow you to compile XML into a SAX producing object (i.e. compiling your configuration files so that reads are blazingly fast). It also provides line precise error messages. It compiles the XML file into an XMLReader compatible class.
Anyway, I can probably leverage the lessons learned from that into the configuration reading code for Avalon... Where else are line-precise error messages used?
to create a runtime object, this location property is applied to the runtime object. The end result is that exceptions in the runtime objects, long after files have been parsed, can be related back to exact locations within the input files. You don't have to sleuth it out from a stack trace, a property of the exception will be the exact location to look. This works out to be a tremendous productivity boost ... you spend very little time guessing at problems, instead the framework directs you to the exact problem. This is all combined with exceptions that include a location property, and Tapestry's exception reporting mechanism is capable of displaying those location properties.
Where should I look for this? I am interested myself in incorporating that functionality.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
