The "One Laptop Per Child" project has a great device ready to ship, but there's no Java on there. Let's think about working together to put Java on OLPC!
Kimberly Horne recently posted an
interesting message
on the
equinox-dev list
; there's some experimental transformations that can be used to select specific views or actions from an existing plugin, but without needing to incorporate everything.
She'd posted a patch
earlier on in the year
, but since being granted
committer status
on the Equinox project, some of the initial code has made its way in an experimental way. You can get a feel for what is possible at the
Product Customisation
page on the Eclipse Wiki site.
There's a number of cool things that can be done here; if you've got a plugin, you can dynamically select which sets of views are present or shown, even if the plugin can contain all the views. It makes it easier to re-use core bundles such as the JDT UI bundle, but without adding unneeded functionality. Or, you could use this to provide a free or basic model, and then allow extended functionality with a registered license code or other activation (e.g. JAAS credentials).
Whilst you can do this manually at the moment by hand-editing the plugin.xml prior to deployment, this is a solution which requires no changes to existing bundles at run-time.
Even more impressively, as well as having XSLT to perform transformations, you can also use a SED transformer, which uses sed/vi type replacements (and therefore also regular expressions)if you're not comfortable with XSLT.
And it doesn't cost extra start-up time if you don't use it, since it's a hook that doesn't have to do any work or even be present in the normal case. How cool is that?
Kim's looking for feedback on the functionality, and this is going to be a very important part of Eclipse RCP apps when it goes live. Here's hoping there will be a long talk on it at EclipseCon next year If you've got any feedback, you can send them via the equinox-dev mailing list, or reply here and I'll forward any responses on to Kim.
I tend to refer to this feature as 'product bastardization' because I think it will encourage products to hack around what they think is wrong with Eclipse instead of reporting back the issue so everyone can benefit from debate and a fix possibly.
Chris, if you didn't notice, reporting back often does not work or get way too long to gt the actual change into the platform.
That Kim's message reminded me an enhancement request I filled in, asking to make title of the "Package Explorer" view shorter. Say, "Packages" (yes I know there is another "Packages" view). So, it won't waste that much space when stacked with other views on the same layout slot. You may easily guess what is the current status of that enhancement request...
I think that's a little idealistic. Haven't you ever wanted to provide, say, the Error Log view in your RCP application but not the Plug-in Registry view? Both of these are provided by the PDE Runtime plugin, so what do you think are my chances of:
(1) Raising a bug to move these two views into separate plugins
(2) Getting the bug fixed in a reasonable timescale for my project (eg 2 months)
(3) Getting the fix applied to 3.2.x, since we can't use 3.3Mx in production.
Actually it turns out you can already turn off views using Capabilities (another of Kim's babies), but the new tranformer stuff will be much more powerful, as capabilities can only switch off extensions when the extension point author does work to explicitly support it. Currently only a few of the extension points in the base plugins (eg org.eclipse.ui) are covered by capabilities.
The other important application for this feature is in role-based authorization, as Alex hinted. I'm hoping to talk about this at EclipseCon, see http://eclipsezilla.eclipsecon.org/show_bug.cgi?id=3889 and please do vote if it takes your fancy!
The problem is that you can't know in advance what combinations of views, actions, or perspectives that a user might want to bundle. For example, let's say you've got a cool XML application. It contributes an XML perspective, an XML editor, and an outline view. However, you only need the outline view to be hooked up to one of your own editors.
The only way to do that is to bastardise the bundle by hand, which doesn't help when updates occur, because you need to re-bastardise the bundle each time.
If they were all true modules, you'd end up with one action per bundle and one view per bundle, and then choose which bundles you want. After all, that's the spirit of OSGi, isn't it? And that's what's given us ever smaller bundles in the Eclipse system that can be combined piecemeal.
The problem is, one module per action/view isn't terribly practical. There's also the fact that if you posted a RFE to (say) JDT UI "please migrate all actions out into their own specific bundles" it would be CLOSED WONTFIX almost immediately.
The problem is that there's no 'product', only OSGi bundles. However, sometimes those OSGi bundles aren't modular enough for other people's preferences. Unless there's a way of making that so (and I don't see why it couldn't be done at the same time), the idea of transforming the plugin is a good step towards doing this dynamically.
Think of it as a kind of reuse. You're re-using the bundle, but only exposing part of it to the application. If they were separate bundles, you'd be able to just select the ones that you wanted. But since you can't, it's either copy-and-paste, bastardise the existing bundle, or use an approach to hide parts of the bundle that you don't need. And with this, any updates to the bundle need no further work on your part.
In any case, RFEs are often pushed to the bottom of the pile and forgotten about, or RESOLVE NEVER. I've been asking for a keystroke for Sort Members (and more recently, having it as part of the cleanup process with the format-on-save stuff), and it's still not part of it. Why? Because JDT/JDT UI team don't sort their members; so they don't need it; so they work on other things. An RFE to ask Eclipse to re-organise some bundles to make a downstream adopter's job easier is less likely to be fixed than that one. This kind of transformation will allow it to be done dynamically, and I don't think it will affect the quality of feedback that you're getting.
Remember, this isn't about bugfixes. It's exposing different subsets of functionality instead of exposing the entire functionality of a single bundle.
Speaking of which; anyone know why they're called "Capabilities" all over the UI, but referred to as "Activities" in all of the code and plugin documentation?
Also note that an Capabactivity is a much larger-grained thing than a single bundle; for example, the 'Team' capability consists of the core team support and cvs support (and presumably, svn support if you have it). The idea of these transformations is very much at the opposite end of the scale; instead of turning everything on or off, you only want to turn off individual views/menus/actions etc.
Capabilities vs. Activities came about as a naming conflict. There was already another component that had laid claim to the word activities and by the time we found out the API was frozen.
Transforming plugin contributions on the fly
At 7:21 PM on Dec 4, 2006, Alex Blewitt
wrote:
She'd posted a patch earlier on in the year , but since being granted committer status on the Equinox project, some of the initial code has made its way in an experimental way. You can get a feel for what is possible at the Product Customisation page on the Eclipse Wiki site.
There's a number of cool things that can be done here; if you've got a plugin, you can dynamically select which sets of views are present or shown, even if the plugin can contain all the views. It makes it easier to re-use core bundles such as the JDT UI bundle, but without adding unneeded functionality. Or, you could use this to provide a free or basic model, and then allow extended functionality with a registered license code or other activation (e.g. JAAS credentials).
Whilst you can do this manually at the moment by hand-editing the plugin.xml prior to deployment, this is a solution which requires no changes to existing bundles at run-time.
Even more impressively, as well as having XSLT to perform transformations, you can also use a SED transformer, which uses sed/vi type replacements (and therefore also regular expressions)if you're not comfortable with XSLT.
And it doesn't cost extra start-up time if you don't use it, since it's a hook that doesn't have to do any work or even be present in the normal case. How cool is that?
Kim's looking for feedback on the functionality, and this is going to be a very important part of Eclipse RCP apps when it goes live. Here's hoping there will be a long talk on it at EclipseCon next year
Alex.
7 replies so far (
Post your own)
Re: Transforming plugin contributions on the fly
I'm not personally a big fan of this approach as I believe it takes away from the spirit of Eclipse. I blogged about it a bit here:http://mea-bloga.blogspot.com/2006/10/product-customization.html
I tend to refer to this feature as 'product bastardization' because I think it will encourage products to hack around what they think is wrong with Eclipse instead of reporting back the issue so everyone can benefit from debate and a fix possibly.
Maybe I'm crazy
Re: Transforming plugin contributions on the fly
Chris, if you didn't notice, reporting back often does not work or get way too long to gt the actual change into the platform.That Kim's message reminded me an enhancement request I filled in, asking to make title of the "Package Explorer" view shorter. Say, "Packages" (yes I know there is another "Packages" view). So, it won't waste that much space when stacked with other views on the same layout slot. You may easily guess what is the current status of that enhancement request...
Re: Transforming plugin contributions on the fly
Chris,I think that's a little idealistic. Haven't you ever wanted to provide, say, the Error Log view in your RCP application but not the Plug-in Registry view? Both of these are provided by the PDE Runtime plugin, so what do you think are my chances of:
(1) Raising a bug to move these two views into separate plugins
(2) Getting the bug fixed in a reasonable timescale for my project (eg 2 months)
(3) Getting the fix applied to 3.2.x, since we can't use 3.3Mx in production.
Actually it turns out you can already turn off views using Capabilities (another of Kim's babies), but the new tranformer stuff will be much more powerful, as capabilities can only switch off extensions when the extension point author does work to explicitly support it. Currently only a few of the extension points in the base plugins (eg org.eclipse.ui) are covered by capabilities.
The other important application for this feature is in role-based authorization, as Alex hinted. I'm hoping to talk about this at EclipseCon, see http://eclipsezilla.eclipsecon.org/show_bug.cgi?id=3889 and please do vote if it takes your fancy!
Re: Transforming plugin contributions on the fly
Chris,The problem is that you can't know in advance what combinations of views, actions, or perspectives that a user might want to bundle. For example, let's say you've got a cool XML application. It contributes an XML perspective, an XML editor, and an outline view. However, you only need the outline view to be hooked up to one of your own editors.
The only way to do that is to bastardise the bundle by hand, which doesn't help when updates occur, because you need to re-bastardise the bundle each time.
If they were all true modules, you'd end up with one action per bundle and one view per bundle, and then choose which bundles you want. After all, that's the spirit of OSGi, isn't it? And that's what's given us ever smaller bundles in the Eclipse system that can be combined piecemeal.
The problem is, one module per action/view isn't terribly practical. There's also the fact that if you posted a RFE to (say) JDT UI "please migrate all actions out into their own specific bundles" it would be CLOSED WONTFIX almost immediately.
The problem is that there's no 'product', only OSGi bundles. However, sometimes those OSGi bundles aren't modular enough for other people's preferences. Unless there's a way of making that so (and I don't see why it couldn't be done at the same time), the idea of transforming the plugin is a good step towards doing this dynamically.
Think of it as a kind of reuse. You're re-using the bundle, but only exposing part of it to the application. If they were separate bundles, you'd be able to just select the ones that you wanted. But since you can't, it's either copy-and-paste, bastardise the existing bundle, or use an approach to hide parts of the bundle that you don't need. And with this, any updates to the bundle need no further work on your part.
In any case, RFEs are often pushed to the bottom of the pile and forgotten about, or RESOLVE NEVER. I've been asking for a keystroke for Sort Members (and more recently, having it as part of the cleanup process with the format-on-save stuff), and it's still not part of it. Why? Because JDT/JDT UI team don't sort their members; so they don't need it; so they work on other things. An RFE to ask Eclipse to re-organise some bundles to make a downstream adopter's job easier is less likely to be fixed than that one. This kind of transformation will allow it to be done dynamically, and I don't think it will affect the quality of feedback that you're getting.
Remember, this isn't about bugfixes. It's exposing different subsets of functionality instead of exposing the entire functionality of a single bundle.
Alex.
Re: Transforming plugin contributions on the fly
Speaking of which; anyone know why they're called "Capabilities" all over the UI, but referred to as "Activities" in all of the code and plugin documentation?Also note that an Capabactivity is a much larger-grained thing than a single bundle; for example, the 'Team' capability consists of the core team support and cvs support (and presumably, svn support if you have it). The idea of these transformations is very much at the opposite end of the scale; instead of turning everything on or off, you only want to turn off individual views/menus/actions etc.
Alex.
Re: Transforming plugin contributions on the fly
Capabilities vs. Activities came about as a naming conflict. There was already another component that had laid claim to the word activities and by the time we found out the API was frozen.Re: Transforming plugin contributions on the fly
Cool, thanks for letting me knowAlex