commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject [HiveMind] HiveMind vs. Eclipse
Date Tue, 09 Sep 2003 17:57:58 GMT
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.

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
View raw message