I'm currently studiying HiveMind for my company, and i must concur : HiveMind documentation is really it's weakness. I had to study twice the time i should have to get all lot "of little example" running...
I dislike web-based documentation, so i print the "all in one pdf" version. It's very good idea but it really how unorganised this doc is ( for instance, the first exmaple you get talk about interception with hivemindlogger but you have to go to the end of the book to find how to implements your own interceptor).
So I vote for a "remake" of this documentation. I'm willing to commit for this new documentation too... But first we have to make a better structure for it ...
2005/5/24, Achim Huegen <[EMAIL PROTECTED]>:
I was hoping to get some feedback on this topic.
Any opinions?
Achim Huegen
Am Tue, 17 May 2005 23:34:00 +0200 schrieb Achim Huegen <[EMAIL PROTECTED]>:
>
> I just came back from the german JAX congress. I attended a workshop that compared Pico, HiveMind and Spring IoC. Good news: HiveMind was not the framework blamed for having the worst documentation ;-) It was a close second place. Close to the third one unfortunately.
> The problem is that the current state of the documentation even leads to wrong statements about HiveMind (for example very lengthy registry setup example, pojo support etc.).
> The feedback from the user mailing list and some other reviews underline the need
> for improval of the doc.
>
> To address this issue I've set up a page on the wiki that tries to identify weaknesses in the current docs and makes a proposal for a new documentation structure:
> http://wiki.apache.org/jakarta-hivemind/DocRevision
>
> I'd suggest this approach:
> - First Release another 1.1 beta or even the final 1.1
> - Discuss and ratify a new documentation structure
> - Find volunteers for each chapter
> - Setup the new site structure and distribute the existing content
> - Vote me in as committer ;-)
> - Write new content
>
> I'm willing to do a (significant) part of the work but I would appreciate to do this as committer. Patching is quite laborious.
>
> Achim Huegen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
