[news.eclipse.technology.equinox] Re: Filtering contributions from depen

[Jeff McAffer <jeff_mcaffer@xxxxxxxxxxxxxxxxx>]

You have hit upon one of the challenges in writing good components -- 
minimizing assumptions and separating concerns.

The XSL transform stuff would be cool.  We'll have to see how that goes 
in 3.3.  Lots of issues...

In the mean time, you might look at the capabilities mechanism that the 
UI team provides.  Basically it allows you to describe sets of 
contributions (views, actions, pref pages, ...) and turn them off and on 
*in the UI*.  It does not remove them from the registry.  In your case 
it seems like you would define a capability that includes all the sutff 
you *don't* want and then turn that off (and hide the mechanism for 
turning that on).

Jeff


Andrei Lissovski wrote:
> Hi,
>
> I am building an RCP application where I need to restrict contributions from 
> certain plug-ins that the application depends on. The main use case is the 
> following:
> I need to provide basic scripting capabilities in my RCP app (think Visual 
> Basic in MS Excel). For that purpose, I am looking into using Ruby 
> Development Toolkit (RDT) which is available as a feature. However, RDT 
> naturally depends on a number of pure IDE plug-ins. As a result, several 
> perspectives and views get contributed that I have no use for in my app. For 
> example, the Resource perspective and the Registers view. I would like to 
> prevent these from being contributed.
>
> I first attempted to go the IExtensionRegistry.removeExtension() route with 
> a null user token (along with setting eclipse.registry.nulltoken=true) but 
> it turns out that these contributions are 'persisted'. As far as I can tell, 
> there is no way to obtain the master token to get around that.
>
> Alternatively, I see that there is machinery around IRegistryProvider but it 
> is not clear to me how to take advantage of that in a clean way. My general 
> thinking was to supply my own registry provider that would delegate to 
> RegistryProviderOSGI and wrap the extension registry returned from its 
> getRegistry(). The wrapper would delegate all calls directly to the original 
> registry, except addContribution() where I would ignore the contributions 
> that I don't want in my app.
>
> Is this the right way to go about this? Do you guys have any pointers as to 
> alternatives?
>
> I also saw it mentioned (in this post by Paul Webster: 
> http://dev.eclipse.org/newslists/news.eclipse.platform.rcp/msg16356.html) 
> that in 3.3 there might be a way to apply an XSL transform to plugin.xml 
> from dependencies. However, I couldn't find any info on that.
>
> Thanks a lot!
>
> -Andrei