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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > >>>>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: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
