commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <>
Subject RE: [HiveMind] Forming the community
Date Mon, 15 Sep 2003 16:26:17 GMT

Howard M. Lewis Ship
Creator, Tapestry: Java Web Components

> -----Original Message-----
> From: Bill Lear [] 
> Sent: Monday, September 15, 2003 10:49 AM
> To: Jakarta Commons Developers List
> Subject: RE: [HiveMind] Forming the community
> On Monday, September 15, 2003 at 10:22:08 (-0400) Howard M. 
> Lewis Ship writes:
> >...
> >I think its about managing dependencies.  HiveMind has limited 
> >dependencies on some other commons projects and on 
> Javassist.  If you 
> >build some HiveMind glue to another project, you may inadventantly 
> >require the other project as a dependency, so you add a few KB of 
> >HiveMinde glue and, possibly, many megs of external dependency. ...
> >So, I'd rather have a new module, say "hivemind.standard.hibernate"
> >that contains wrappers around Hibernate than have those wrappers part
> >of the main library whether you use Hibernate or not.
> >...
> Good points, I agree.
> >Sounds like a decent idea for me; we're doing something similar at 
> >WebCT shortly and I'm pushing to leverage HiveMind. Now if 
> only I could 
> >MANDATE it ...
> You've been reading Nietzsche again, haven't you!
> I've just successfully built and run the example you provide 
> in the documentation.  This is a good start.  I do think that 
> the example in particular, and HiveMind in general, would be 
> helped by a discussion of the advantages of declarative 
> programming and how it can be used to simplify testing of 
> applications.  I liken this to Laplace transforms, with which 
> one transforms work to be performed from one domain that is 
> difficult, into another which is easier.  A mention of why 
> certain parts of the application are transformed 
> (construction of services), and not others, would also be 
> helpful to guide developers in their choices.

That sounds like a good idea of another sub-project, an example that demonstrates some useful
you can easily do in HiveMind, including unit tests.

> Extending this, one needs to show exactly how programming for testing
> (PFT) becomes possible or at least much easier.  Without such 
> a concrete demonstration of the ease of switching between 
> production and testing implementations, the plumbing looks to 
> the untrained eye to be just so much dressing for no purpose.

Excellent point, and an excellent area for contributions ... justifying HiveMind after the

> So, I would suggest as we move forward that we realize our 
> high-level goals directly in the example.  So, the example 
> should include multiple independent HiveMind services 
> ("independent" yoked to HiveMind is of course redundant) and 
> perhaps an application that uses these services in 
> production, and also, mock services (if that is the 
> appropriate term) that implement the services for testing purposes.
> This brings another thing to mind: would it be 
> appropriate/possible for HiveMind services to also provide a 
> mock version of their service? Or is the particular 
> implementation of mock services too much dependent upon the 
> application in which they are used?

I think it would be hard to pin down; MockObjects can create mockups, but you need a reference
the mock-object-generator class to tell the mockup how to behave.  In other words, you need
to the service and its implementation, and HiveMind only gives you the service.

You could imagine, though, a MockInterceptor that you could use for these purposes in some
way (just
not sure what that way is).

I picture the unit testing story for HiveMind to be the unit test acting as the container,
instantiating core service implementations and settting properties to point at each other,
invoking methods.

Howard M. Lewis Ship
Creator, Tapestry: Java Web Components

View raw message