> >From: "Howard M. Lewis Ship" <[EMAIL PROTECTED]> > >> > >> - 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 a 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, stateful 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 modules. 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" module packaged together in a single JAR. -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Tapestry: Java Web Components http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
