[HiveMind] Question about HiveMind scope and purpose

[Berin Loritsch <bl...@d-haven.org>]

Someone pointed out to me that there is a Commons Sandbox project
called HiveMind, and according to the docs at
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/hivemind/xdocs/index.xml
it sounds a *lot* like Avalon.

Instead of reinventing the wheel, what about collaborating with
the Avalon team to correct what you feel are deficiencies and
work from there.

The Avalon team is in a place where they are evaluating what they have,
and where they want to go from there.



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [HiveMind] Question about HiveMind scope and purpose

[Berin Loritsch <bl...@d-haven.org>]

Howard M. Lewis Ship wrote:

> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

RE: [HiveMind] Question about HiveMind scope and purpose

["Howard M. Lewis Ship" <hl...@comcast.net>]

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 feel HiveMind is entering a more stable stage after its chaotic birth.  I believe it is just about
at the point where other interested parties might want to join in the fun!

As I've mentioned before, HiveMind is something of an experiment.  A chance for me to learn Maven,
to establish a project properly within Jakarta and so forth.  Hey, I finally learned some XSL!

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 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.

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.

[*] 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
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.

One of the reasons I've been rolling out HiveMind is to seperate this very useful functionality from
Tapestry.  In fact, Tapestry 3.1 will move a lot of code from Tapestry to HiveMind.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry



> -----Original Message-----
> From: Martin Cooper [mailto:martinc@apache.org] 
> Sent: Tuesday, July 08, 2003 3:17 PM
> To: Jakarta Commons Developers List
> Cc: hlship@apache.org
> Subject: Re: [HiveMind] Question about HiveMind scope and purpose
> 
> 
> 
> 
> On Mon, 7 Jul 2003, Berin Loritsch wrote:
> 
> > Berin Loritsch wrote:
> >
> > > Someone pointed out to me that there is a Commons Sandbox project 
> > > called HiveMind, and according to the docs at 
> > > 
> http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/hive
mind/x
> > docs/index.xml
> >
> > it sounds a *lot* like Avalon.
> >
> > Instead of reinventing the wheel, what about collaborating with the 
> > Avalon team to correct what you feel are deficiencies and work from 
> > there.
> >
> > The Avalon team is in a place where they are evaluating what they 
> > have, and where they want to go from there.
>
> Is HiveMind in active development?  Any interest at all?

It seems to be in development, but only by hlship. I suspect he isn't on this list, so I'm cc'ing
him to see if we can provoke a response. ;-)

--
Martin Cooper


>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [HiveMind] Question about HiveMind scope and purpose

[Martin Cooper <ma...@apache.org>]

On Mon, 7 Jul 2003, Berin Loritsch wrote:

> Berin Loritsch wrote:
>
> > Someone pointed out to me that there is a Commons Sandbox project
> > called HiveMind, and according to the docs at
> > http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/hivemind/xdocs/index.xml
> >
> > it sounds a *lot* like Avalon.
> >
> > Instead of reinventing the wheel, what about collaborating with
> > the Avalon team to correct what you feel are deficiencies and
> > work from there.
> >
> > The Avalon team is in a place where they are evaluating what they have,
> > and where they want to go from there.
>
> Is HiveMind in active development?  Any interest at all?

It seems to be in development, but only by hlship. I suspect he isn't on
this list, so I'm cc'ing him to see if we can provoke a response. ;-)

--
Martin Cooper


>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [HiveMind] Question about HiveMind scope and purpose

[Janek Bogucki <ya...@studylink.com>]

On Mon, 2003-07-07 at 15:29, Berin Loritsch wrote:
> Berin Loritsch wrote:
> 
> > Someone pointed out to me that there is a Commons Sandbox project
> > called HiveMind, and according to the docs at
> > http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/hivemind/xdocs/index.xml 
> > 
> > it sounds a *lot* like Avalon.
> > 
> > Instead of reinventing the wheel, what about collaborating with
> > the Avalon team to correct what you feel are deficiencies and
> > work from there.
> > 
> > The Avalon team is in a place where they are evaluating what they have,
> > and where they want to go from there.
> 
> Is HiveMind in active development?  Any interest at all?
>

There has been some recent development:

http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/

-Janek

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [HiveMind] Question about HiveMind scope and purpose

[Berin Loritsch <bl...@d-haven.org>]

Berin Loritsch wrote:

> Someone pointed out to me that there is a Commons Sandbox project
> called HiveMind, and according to the docs at
> http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/hivemind/xdocs/index.xml 
> 
> it sounds a *lot* like Avalon.
> 
> Instead of reinventing the wheel, what about collaborating with
> the Avalon team to correct what you feel are deficiencies and
> work from there.
> 
> The Avalon team is in a place where they are evaluating what they have,
> and where they want to go from there.

Is HiveMind in active development?  Any interest at all?



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [HiveMind] Question about HiveMind scope and purpose

[Berin Loritsch <bl...@d-haven.org>]

Berin Loritsch wrote:

> Someone pointed out to me that there is a Commons Sandbox project
> called HiveMind, and according to the docs at
> http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/hivemind/xdocs/index.xml 
> 
> it sounds a *lot* like Avalon.
> 
> Instead of reinventing the wheel, what about collaborating with
> the Avalon team to correct what you feel are deficiencies and
> work from there.
> 
> The Avalon team is in a place where they are evaluating what they have,
> and where they want to go from there.

Is HiveMind in active development?  Any interest at all?


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [HiveMind] Question about HiveMind scope and purpose

[Martin Cooper <ma...@apache.org>]

I saw HiveMind appear in the sandbox, but didn't really pay any attention
to it until I saw Berin's message, below. Has there been any discussion of
the similarities and differences between Avalon and HiveMind anywhere? I'd
be rather interested in reading about that.

--
Martin Cooper


On Fri, 27 Jun 2003, Berin Loritsch wrote:

> Someone pointed out to me that there is a Commons Sandbox project
> called HiveMind, and according to the docs at
> http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/hivemind/xdocs/index.xml
> it sounds a *lot* like Avalon.
>
> Instead of reinventing the wheel, what about collaborating with
> the Avalon team to correct what you feel are deficiencies and
> work from there.
>
> The Avalon team is in a place where they are evaluating what they have,
> and where they want to go from there.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org