commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <hkrishnasw...@comcast.net>
Subject Re: [HiveMind] HiveMind vs. Eclipse
Date Wed, 10 Sep 2003 04:28:50 GMT
I think I see your point now. Eclipse is a platform and a registry of 
extensions to the platform. HiveMind is just a registry of services and 
configuration.

Howard M. Lewis Ship wrote:

>Eclipse just has <extension-point> and <extension>
>
>As with HiveMind, you can have <extension>s in many plug-ins contribute to the same
><extension-point>.
>
>The <extension-point> gets all the contributions in a DOM-like format (thinly disguised
XML elements
>and attributes).
>
>Eclipse <extension-point>s can have a schema (in W3C Schema format, roughly), but
that appears to
>only be used by the PDE (this is not verified, however).  Eclipse doesn't have the equivalent
of
>HiveMind's <schema>, <element>, <attribute> and <rules> for runtime
(not buildtime) validation and
>conversion.
>
>Eclipse includes a special case for dealing with classpath issues when a contribution
is the name of
>a class; it hooks into the right class loader and may activate the plugin when a class
is
>instantiated.  Beyond that, Eclipse doesn't have a service model.
>
I think this is where the disconnect is. It is exactly because of this 
hook that I thought eclipse extensions are similar to services. But I 
see your point that services have various models and that a service can 
only be contributed to once. In that respect I agree that HiveMind 
extension-points are more similar to the Eclipse extension-poits than 
services. On another angle though, Eclipse is a platform and a registry 
of extensions to the platform while HiveMind is just a registry of 
services and configuration, nothing to extend, so from my understanding 
so far, my names for today are <service-point...> and 
<configuration-point...> :).

>
>Perhaps you are confused by the ability to pass parameters to a service implementation
factory (such
>as hivemind.Builder)?  That looks like an <extension> (and leverages the same code),
but only a
>single module may contribute a service constructor, and therefore, there won't be multiple
><invoke-factory> elements for any given service.  Multiple modules may contribute
an <interceptor>.
>
>HiveMind <interceptor>, <service>, <extend-service>, <create-instance>
and <invoke-factory> don't
>have any parallels in Eclipse, beyond the limited support for passing a class name as
an attribute
>in a contribution. From code I've looked at, different plugins will cooperate by accessing
each
>other's Plugin singleton's (via static methods).
>
>Also, to my knowledge, Eclipse is not expressly thread-safe.  HiveMind is (to the best
of my
>knowledge).
>
>
>Note: moved this over to Jakarta Commons Developer.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>http://jakarta.apache.org/commons/sandbox/hivemind/
>http://javatapestry.blogspot.com
>
>  
>
>>-----Original Message-----
>>From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] 
>>Sent: Tuesday, September 09, 2003 11:45 AM
>>To: Tapestry development
>>Subject: Re: HiveMind feedback/questions
>>
>>
>>
>>
>>Howard M. Lewis Ship wrote:
>>
>>    
>>
>>>>>>-----Original Message-----
>>>>>>From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
>>>>>>Sent: Monday, September 08, 2003 4:20 PM
>>>>>>To: Tapestry development
>>>>>>Subject: HiveMind feedback/questions
>>>>>>
>>>>>>
>>>>>>I put the Adder example together with a 
>>>>>>            
>>>>>>
>>LoggingInterceptor in three 
>>    
>>
>>>>>>modules and its pretty slick. Although the free form 
>>>>>>            
>>>>>>
>>schema gets my 
>>    
>>
>>>>>>head spinning ;). I think it'll take a little bit to get adjusted
>>>>>>to living 
>>>>>>without constraints! I like the fact that it can support 
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>both IoC and 
>>>>   
>>>>
>>>>        
>>>>
>>>>>>SoC, nice! And the documentation is great.
>>>>>>
>>>>>>I have a few questions:
>>>>>>1. What is rationale behind the names <service...> and
>>>>>><extension-point...>? That would probably clarify my 
>>>>>>confusion with the 
>>>>>>names. 
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>The naming is a bit tricky.  I eventually ended up with 
>>>>><extension-point> and <extension> because that part of 
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>HiveMind is very 
>>>>   
>>>>
>>>>        
>>>>
>>>>>close to Eclipse's plugin model; I decided that rather than have 
>>>>>competing names, I'd use the Eclipse names.
>>>>>
>>>>>To some degree, I wish I had gone with an earlier idea that 
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>I discarded 
>>>>   
>>>>
>>>>        
>>>>
>>>>>(can't remember why) where an extension point could be either a 
>>>>>configuration extension point, a service extension point, or both.
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>I had the same thought, but then I thought you might have 
>>>>differentiated 
>>>>them because of the special service contributions (create-instance, 
>>>>...). The other way would have definitely been much more 
>>>>simpler. Also, 
>>>>I had all along thought that the Hivemind service was 
>>>>analogous to the 
>>>>eclipse extension-point because they both provide behavioral 
>>>>extensions, 
>>>>while Hivemind extensions as such only provide objects that 
>>>>have to be 
>>>>manipulated by a service or something, am I at a loss here?
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>The plugin API is very, very close to the extension points; 
>>>      
>>>
>>it doesn't really have the concept of a
>>    
>>
>>>service.
>>>It does have special hooks that do the right class loader 
>>>      
>>>
>>thing when a contribution is the name of a
>>    
>>
>>>class. Eclipse doesn't have the <rules> thing to convert the 
>>>      
>>>
>>contributions directly into Java
>>    
>>
>>>objects ... most Eclipse plugins are full of code to walk 
>>>      
>>>
>>elements and attributes and do the
>>    
>>
>>>conversions.
>>> 
>>>
>>>      
>>>
>>This is certainly one area where Hivemind overtakes Eclipse. Using 
>>Hivemind to build Eclipse would have been a lot more simpler! 
>>But I am 
>>sorry, I still can't see difference between services and eclipse 
>>extension points, is it because extension points cannot take 
>>interceptor 
>>and factory contributions? But conceptually though, from my 
>>understanding, services and eclipse extension points can both take 
>>behavioral contributions and Hivemind extension points 
>>cannot. Sorry to 
>>belabor the point, may be I have to do more reading.
>>
>>    
>>
>>> 
>>>
>>>      
>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>It got me a little confused initially,
>>>>>><service-extension-point...> and 
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>><config-extension-point...> is more 
>>>>   
>>>>
>>>>        
>>>>
>>>>>>intuitive to me.
>>>>>>2. How to debug deferred services when dynamic proxies are 
>>>>>>used?
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>Place your breakpoints inside your service implementation class.  
>>>>>Proxies and interceptors shouldn't need to be debugged.  In 
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>some cases, 
>>>>   
>>>>
>>>>        
>>>>
>>>>>there's a method in an abstract class you can place breakpoints in.
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>I was actually trying to trace the call-chain from 
>>>>RegistryBuilder and 
>>>>couldn't proceed after I hit the proxy but I guess I can switch the 
>>>>service to Singleton for this purpose, right? I shall try 
>>>>this tomorrow.
>>>>   
>>>>
>>>>        
>>>>
>>>Yes, that's a disadvantage of creating the code at runtime; 
>>>      
>>>
>>there's no "source code" for the
>>    
>>
>>>debugger to step through. The advantages, even over 
>>>      
>>>
>>something like XDoclet, is much easier build
>>    
>>
>>>time environment, and always perfectly in-sync, fewer 
>>>      
>>>
>>build-time artifacts (such as generated Java
>>    
>>
>>>files), etc.
>>>
>>>      
>>>
>>No argument here!
>>
>>    
>>
>>>--
>>>Howard M. Lewis Ship
>>>Creator, Tapestry: Java Web Components
>>>http://jakarta.apache.org/tapestry
>>>http://jakarta.apache.org/commons/sandbox/hivemind/
>>>http://javatapestry.blogspot.com
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>
>>>
>>> 
>>>
>>>      
>>>
>
>
>  
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message