I have a set of plug-ins which need to support different Eclipse products. There is a core plug-in, which is product-independent, and an adaptation plug-in each for Product X, Product Y, etc.
Deployment-wise, I'm thinking one feature for the core plug-in and one for each product, containing the adaptation plug-in and having a dependency to the core feature, so the core plug-in gets installed without the user having to select it.
1) Is there a better way of structuring the features?
On the development side, I would like to be able to work with both the core and adaptation plug-ins within the same workspace, which as I understand it gives me two main options: a) working within each product using their respective installations as target platforms, or b) working in raw Eclipse with an explicitly defined target platform for each product.
2) What would be the best way to set up the development environment?
If option a), can I use the same workspace for different products or would I need to set up separate workspaces? In other words, are different Eclipse products able to share a workspace as long as they're all based on the same (say) major version, eg 3.x?
If option b), can Eclipse manage multiple simultaneous target platforms? In other words, can different plug-in projects within the same workspace be compiled against different target platforms during the same build? And if not, how could I automate switching between them so I wouldn't have to do that manually during a workspace build?
Or indeed, am I missing something fundamental and is there a much better way of doing all this?
The short answer is you can do it either way.
You can have 1 workspace per product, and each workspace has the target platform of that product. At the moment, eclipse supports one target platform active per workspace, not per project though.
Or you can have eclipse and the 3rd party plugins you need as your target platform, and simply work on all 3 products and the common plugin in one workspace. If your total source plugins is <20, this would probably be fine. For >20, eclipse supports Working Set which would hide the plugin you are not working on at the moment.
Related
I have an Eclipse-based OSGi application consisting of bundles organised in features. I use a product definition to launch the application. In this definition, I can also set start-levels for my bundles.
Now imagine I want to add a feature to the running application. Is a p2.inf file the only way to specify start levels for the bundles in this feature? Re-defining and re-starting the product does not sound like an optimal solution as it's not really dynamic.
I am not aware of any real tooling support for setting start levels for bundles on the feature level. The only option you have is manual hacking with a p2.inf.
I think the reason that setting start levels is only really supported for products is that p2 can't handle the case where start levels are specified multiple times. This could easily happen if setting start levels on feature level was encouraged.
So, you can make this work on feature level, but only if you know what you do.
I have the same problem I believe: I have a feature that is both part of a packaged product and present on an update site to be installed into an Eclipse IDE. And I also want to set the start-level for some of the plug-ins to ensure a very early start-up.
I have overcome this with a p2.inf file with the following content:
instructions.configure=setStartLevel(startLevel:1);markStarted(started: true);
instructions.unconfigure=setStartLevel(startLevel:-1);markStarted(started: false);
(I don't think I need to specify the start-level in the product definition anymore though I have not tried to remove this yet.)
I originally used start-level 2, but at least for Juno packages, there are some plug-ins that are started at level 1 so I now use level 1 as well.
I am developing an RCP application and I am also implementing p2 updates for it.
I am using this link as guide to implement p2 updates.
For example I have 3 plug-ins A, B and C in my application.
Where Plugin A represent the core functionality of my application. Plug-in B is one more mandatory plugin. While plugin C is optional.
I have created 3 feature projects. Where FeatureA contains plug-in A and dependent libraries.
FeatureB contains plug-in B and dependent libraries. While FeatureC contains plug-in C and dependent libraries.
There are certain libraries which are common across these 3 plug-in e.g. birt, nattable. How should I structure them. Currently I am adding them in each feature project independently. What is the better way to structure feature projects? Kindly guide me.
When you have a common subset of plugins that your features require, you could make another "Requirements" feature which includes the required plugins and then require that feature in your existing features. This makes it easier for you to change your set of required plugins over time.
One downside of this approach is that Feature B may not need all of the plugins from the common feature which means if you ship Feature B without Feature A it could ship more plugins than you intend.
Another item you should consider is will you be updating the features independent of each other? If you require all versions of your features to be the same, then having the new Requirements feature makes sense. But if Feature A can upgrade to version 2.0 while Feature B remains at 1.0 you will encounter provisioning conflicts if you have singleton plugins.
One more thought is that since you're creating an RCP, you may just want to run the p2 publisher over your product file to produce a lineup IU. This produces much more deterministic provisioning of your RCP application. If you're creating a simple RCP which doesn't have the standard Eclipse About dialog, then you wouldn't even need to expose features.
As a final note, you could just buy update functionality. Having written this technology for the past 5 years I can tell you there are many pitfalls. My company's product, Secure Delivery Center, makes it easy to ship your software and includes simple update support.
Together with my team I'm developing multiple native plugins based on Trigger.io. Since the recent changes I'm not completely sure on the workflow and cannot find anything about it in the documentation either. Some questions that arise:
1) Should one set of inspector projects be used for all the plugins or should each plugin has its own set?
2) Which parts of the inspector projects should be maintained via version control, which should remain local? (fyi: we use SVN)
3) (Android) When using one inspector project for each plugin, whats the best way to import them all as Java projects in Eclipse? Note: each inspector project has 3 sub projects which have the same name across different plugins, so they'd have to renamed? Assuming I have 5 plugins in development, that'd mean that I have to import 15 Java projects into Eclipse. Is this really how it's meant to be?
The most effective way to develop plugins is still something we're working on, how things are right now is probably not as good as it could be (especially for developing multiple plugins), but as things are right now:
1) Each plugin should have its own set of inspector projects.
2) The majority of what the Toolkit puts in the plugins folder is probably best in version control. Things you can safely ignore are the .trigger folder and any bin, gen, or build folders in the inspector projects. If you are trying to keep less files in version control the things you definitely need are the assets/src folder in the ForgeInspector, and any of your own source in ForgeModule, the rest of the inspector project should be regenerated by the Toolkit.
3) I'd recommend using an eclipse workspace per plugin, as the Toolkit regenerates a lot of the code when you update the inspector I don't think it is currently possible to rename the projects.
I thought I'd include a quick overview of what the 3 projects are and why there are 3:
ForgeCore - This is the pre-build core library for Trigger.io apps, its used by both ForgeInspector and ForgeModule so it needs to be a separate project that can be referenced by both
ForgeInspector - This is meant to replicate as closely as possible how your plugin will actually be used, so is basically a stripped down Trigger.io app, its separate to ForgeModule so that you can see what code is in your plugin and what code needs to be put into build_steps.json so it will also be applied to a real Trigger.io app at build time.
ForgeModule - This contains your plugin code
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