In the context of an RCP application I am wondering if I should base my product on plugins or on features.
The main difference I can see for now is about the content of the exported application.
Using plugins as product base result in an exported (with GUi or headless build, it's the same) with ALL the required plugins (computed I guess through plugins manifest).
On the opposite, when using feature as bases the exported product only contain the listed features in the product file. Thus I have to add manually add all the required features in order to let my product work correctly. This also has the side effect to bring all the features plugins even if they are not needed.
What are your experiences on the subject ?
EDIT As suggested by Vonc comments I created my own feature including only plugins I need from other features. This solution works but I have to manually add all the required plugins by my product in this feature. Today to do that, the only solution I found is to use the launch configuration plugins tabb with the compute required plugins button and to report by hand in my feature all the selected plugins. It's really boring :-( Is there any other solutions existing ?
Thanks
After many investigations here is a "clear" (I hope) status on the subject.
Plugin Products:
No problem when building (Gui or headless) => all the required (the same than the required plugins computed in the launch configuration dialog when debugging the app) plugins are present
The RCP application disk footprint is optimized !! No useless plugins
No features are exported: as a ressult the features list tab of about dialog is empty !!!
It seems that plugin products are not recommended for RCP with self update (I didnd't tested that yet)
Feature Products:
When exporting (headless), the only present plugins and features are the one listed in the .product file
Need to create a "dependencies" features including all the required plugins OR depend on all the features containing the required plugins => bring a lot of useless plugins
Features listed in the about dialog
In my personal situation, I decided to use a Feature Product and then to "manually" create a feature including all the 90 plugins required by my RCP.
Because I am lazy and hate repetitive tasks, I wrote a simple Java main parsing a launch configuration file (.launch located in the workspace metadata folder) and generating from a template the feature with all the required dependencies.
Hope this can help others, and if you need my simple Java feature dependency creator, just ask it.
Manu
Related
I have an Eclipse RCP application with plugins and associated test fragments. When using the "Add required plugins" functionality in the launch or product configuration, the test fragments get added as well.
Can I avoid this? My plugins don't depend on their fragments, and I'd like to select only the "real" dependencies.
Add Required Plug-ins will always include fragments. Unfortunately, there is currently no way to control whether fragments are included or not.
You will need to manually de-select the unwanted fragments.
I have an Eclipse-RCP project with multiple product_configuration.product files.
They are sort of siblings; product-B has all product-A's dependencies but have different launching/configuration.
The problem comes when I add a new plug-in to product-A (which I launch the most often), and then forgot to add the plug-in to product B,C,D etc.
It stays hidden until I actually launch/export the other configuration; only then I see it's missing and it's a bit painful.
Is there any way to solve this without manually adding plug-in dependencies into each product?
You could use a Feature based configuration rather than just plugins. Then you can have one or more common features used by all of the products and other features containing the plugins unique to each product.
Some more on features here
I already have a standalone Eclipse RCP application. The next task is to integrate the plugins which are widely used in the Eclipse community like CDT or say PyDev to provide the editing and debugging facilities in respective programming languages inside the already developed RCP app. Just wondering how do i go about accomplishing this task. Should i start with playing around the extension points of the plugins and adding it to the MANIFEST.MF ?
What are the various ways of achieving this ? Which one to pick over the other?
The most important thing you should consider (besides the technical) is a conceptional.
Plugins like CDT are making a lot of assumptations about their environment they are integrated into. That means your RCP should have a very similar user-interface and behavior like the normal Eclipse SDK so that the integration of other "IDE-ish" plugins is not a break of the interface principles of your RCP.
If your RCP is not based on a common navigator, projects, files (in general the Workspace) and several editors the integration of Plugins like CDT will be a nightmare for your users and will feel like another application within your RCP.
Make also sure that ui-contributions from third-party-plugins are visible (e.g. if the third-party-plugin is contributing a preference page, make sure that your RCP has the menu-item to open the preference-window)
First you have to load the new features/plugins in your existing RCP application. For this you have to adapt your product definition and load the new feature.xml files. or you enhance your own feature.xml and place the new plugins into.
Afterwards you have to decide, whether the new functions/view/perspectives are contributions to an already existing RCP extension point and whether you use this extension point in your RCP product.
If you want to use the new functions in another way (because the default is not enough) you have to point to specific views/actions in the new plugins and call them by your self. Fot his you have to adapt the MANIFEST.MF of your own plugin and point to the new plugins. If you do it, you can not switch off the added features, because you do have a jard link to these plugins.
Your RCP product already depends on the RCP feature (org.eclipse.rcp) or a subset of its plug-ins. This means, it already includes the plug-ins defining the basic extension points.
To include functionality (extensions) from additional features, just add these features to your product configuration dependencies. For example, you would have to add the feature org.eclipse.cdt for CDT and org.python.pydev.feature for PyDev.
The hard part begins when you need to include only some of the features' plug-ins.
You'll have to isolate the plug-in(s) providing the functionality you require.
For UI contributions, you can use the plug-in selection spy by selecting the required UI part and clicking alt+shift+F1.
For non-UI contributions, information for contributed extensions can be found in the plugin.xml files in the plug-in sources.
These plug-ins, along with their dependencies can be added to a custom feature, which can be included in your product.
Although dated, the article Building a CDT-based editor might also be of help.
Working Eclipse features and plugins, I have a problem with building two separate features (lets call them One and Two) where Two contains plugins that depend on plugins in One. I use PDE Build and ideally would like to have the option to build just One or Two (assuming One was built at some previous point in time).
However, having built One and then trying to build Two I run into the problem that classes that were built in One cannot be resolved. I am trying to get the second build to use the .jar files which were the output of building One, but have had no success. It simply seems it ignores the build output from One.
I've tried various solutions, like using build.properties pluginPath property to refer to the .jar files I depend on. Copying the already built plugins into buildDirectory is not a good option either, since the environment I am working in is a bit messed up and the build directory also contains other plugins that are not to be built (including the plugins built with One).
Any suggestions are welcome!
Cheers,
Anders
In PDE, features are just sets of plugins. This is meaningful during installation but not during build. So you can't say "plugin X depends on feature Y", you can only say "plugin X depends on plugin Z"
So what you need to do is this:
Add dependencies to the plugins in Two which mention the plugins from One
Add One to the "target platform definition". This is basically a list of plugins which will be available when the plugins of Two will be installed at some time in the future.
This blog post should get you started how to create your own target platform.
[EDIT] These two blog posts might also be useful:
http://pweclipse.blogspot.com/2011/02/pde-build-as-workspace-export.html
http://www.vogella.de/articles/EclipsePDEBuild/article.html
I have a handful of Eclipse plugins that I maintain. They are proving useful enough that non Eclipse users have asked for them without the overhead of a full eclipse install.
I am certain this is possible, but uncertain how to make this possible. My attempts at creating a standalone RCP app and then including my plugins as dependencies have given me mixed results. More specifically, my perspective tries to instantiate a view from a plugin and fails (silently)...
public void createInitialLayout(IPageLayout layout) {
layout.addStandaloneView( "myPlugin.ID", false, IPageLayout.LEFT, 0.25f, editorArea);
}
... but as the same plugin implements a search extension, it does show up in the standard Eclipse search dialog.
Are there any resources that hardened Eclipse tars can point me to, that will help overcome this hurdle?
M.
What i did is to make the plugin project to dependent on org.eclipse.ui.ide.application and a few other core eclipse plugins. And then I create a new product configuration, make org.eclipse.ui.workbench as the application. I can also define my own icons, splash to do some branding. Then i can export the product to be a stand alone application with my plugin in it.
One lead to follow is the notion of product build, based on Equinox/p2/Adding Self-Update to an RCP Application.