In Eclipse 4.26, it says that.
Additionally the slf4j.api Plugin as well as org.apache.commons.logging have been removed from all Features of the Eclipse Platform to enable Application/Product builders to freely choose the logging-framework and bridging strategy eventually used in their product.
But how to do it? Is there any more information ?
Related
We recently decided that we want to share our Eclipse warnings settings so that all developers use the same ones (also save actions and formatter configuration). This of course means we want to remove all project specific settings. We created all the necessary plug-ins from scratch and are now able to display problems with quickfixes whenever project specific settings are still present.
So we now came to know that M2E selects the checkbox "Enable project specific settings" for the preference page "Java Compiler -> Errors / Warnings" on any Maven update (which usually happens quite often).
(Or adds the key value pair org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning to .settings\org.eclipse.jdt.core.prefs.)
I think it's clear that it's absolutely unacceptable for a build tool to create project specific settings of any kind, much less to tinker with the forbidden references.
So how do I prevent M2E from doing just that?
I have a requirement to design a plugin which is OS specific. Depending on OS (MAC or Windows), the content of the plugin will vary.
Currently we are maintaining two different plugins, one for Windows and other for MAC, plugin id's com.core.win and com.core.mac.
My main plugin is dependent on above plugin. But as my plugin ID is different depending on OS, both the plugins are added in Plug-ins Dependency as "Optional".
com.core.win; resolution:=optional,
com.core.mac; resolution:=optional
But in reality the dependency is a must, "Required". How do I design my plugin structure, such that a tight dependency can be defined ? Is there any standard solution approach ?
Thank You!
Usually you have one base plugin with a platform specific fragment for each platform.
You use the Eclipse-PlatformFilter MANIFEST.MF entry to specify the platform, something like:
Eclipse-PlatformFilter: (& (osgi.ws=cocoa) (osgi.os=macosx) (osgi.arch=x86_64) )
which specifies the Cocoa window system, Mac OS X operating system and 64 bit (this is the normal setting for current Macs).
In the plugin.xml/MANIFEST.MF editor this is the 'Platform Filter' field in the 'General Information' section of the 'Overview' tab.
Here is a good introduction about fragments, the Eclipse PDE Help also has documentation. Also, SWT is a good example of usage of fragments for platform-specific code. See this FAQ entry to learn how to get the SWT code for inspection (you don't need to actually do the build and export part).
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.
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.
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