Howard M. Lewis Ship wrote:
I am a big +1 on this approach. My modules are already too big with a lot of configurations.From: "Howard M. Lewis Ship" <[EMAIL PROTECTED]>level, not the
- I believe your placeholder for version checking is at the wrong level.
I think versioning should be at the service interface
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.
On a related topic, Geoff asked about private services a few days ago - services that should not be available to clients (via registry.getService() I presume), only to other services via injection. What do you think about that?
--
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
