Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <4046396B.4010802@comcast.net>
Date: Wed, 03 Mar 2004 15:00:43 -0500
From: Harish Krishnaswamy <hkrishnaswamy@comcast.net>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [HiveMind] HiveMind ideas
References: <026801c40158$dc6123c0$6401a8c0@ALMIGHTYBEAST>
In-Reply-To: <026801c40158$dc6123c0$6401a8c0@ALMIGHTYBEAST>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Howard M. Lewis Ship wrote:

>>>From: "Howard M. Lewis Ship" <hlship@comcast.net>  
>>>      
>>>
>>>>- 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.
>  
>
I am a big +1 on this approach. My modules are already too big with a 
lot of configurations.

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