Re: [HiveMind] HiveMind vs. Eclipse

[Harish Krishnaswamy]

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