commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <>
Subject RE: [HiveMind] HiveMind ideas
Date Wed, 03 Mar 2004 19:50:59 GMT
> >From: "Howard M. Lewis Ship" <>  
> >> 
> >> - I believe your placeholder for version checking is at the 
> >> wrong level.
> >>  I think versioning should be at the service interface 
> level, not the
> >> module level.  Isn't that how Eclipse does it?  What are your 
> >> thoughts here?
> >
> >I'm pretty sure module level makes sense. Eclipse does it that way.
> Right you are -- I misremembered.  However, let me expand a bit on my
> theory.
> A HiveMind module may supply lots of service interfaces.  Now, you
> *might* want to manage all of these services' versions with a single
> module-wide version -- as you have it.  But you might instead want to
> manage their versions individually.  Why?  Well, otherwise your 10
> stable services will appear to have changed incompatibly when you have
> to bump your module's version number to satisfy your 1 
> rapidly changing
> service.
> I'm anticipating being able to specify the version number 
> required when
> wiring up a service, and when providing an implementation, with the
> meanings for version numbers that Eclipse uses.  (Namely: a change to
> the major number means a potentially incompatible change, and a change
> to the minor number means backwards compatible.)
> This seems useful to me, when trying to manage lots of independently
> developed services, which is what I'm trying to do.

Rapdily changing interfaces?  Not just implementations, but interfaces? That sounds more like
alpha cycle than a full release cycle.

I'm beginning to see that your interfaces will stay simpler and more stable. HiveMind gives
you a
lot of tools (on-the-fly service construction, dependency injection, event notifications,
service models) so that its' very easy to create simple facade interfaces around more intracate,
collaborative services.

Back to your issue. One solution is to use a more fine grained approach; have many seperate

I think, to support that approach, HiveMind may need a way to break the "one jar == one module"
approach.  Perhaps an element of the module descriptor could be a path to *additional* module
descriptors to read.  

In other words, you can have a "myco.mypackage.public" module and a "myco.mypackage.private"
packaged together in a single JAR.

Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message