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).
Related
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 am building an application whose GUI should look like eclipse. Since Eclipse uses Equinox OSGi framework, is it possible to reuse the bundle responsible for Eclipse GUI in my application? If so, which is the bundle which is responsible for Eclipse GUI?
Any help is appreciated..!
I believe you are making a wrong assumption: Out of the many bundles (a.k.a. plugins) that an Eclipse installation normally consists of, there is not a single bundle responsible for the overall GUI. Instead it is a large chunck of dependent bundles for the SWT graphics library, the views, workbench and so.
So if you want to create something that looks like Eclipse and behaves like Eclipse, then you want to reuse many of those plugins and you probably want to read further on the Eclipse Rich Client Platform, which is the smallest set of reusable bundles for creating Eclipse-based applications.
For building Eclipse-alike application you can of course extend the Eclipse platform using an own plugin. However OSGi can be very complex.
If you only want the general look of Eclipse you just use SWT: The Standard Widget Toolkit. This toolkit provides the GUI elements and is responsible for the look of Eclipse.
This is possible but a bit complex. Download the archives for SWT (basic building blocks like labels, buttons and tables) and possibly JFace (high level UI components) and add the JARs to your classpath.
One way to get them is to download Eclipse for your platform; that gives you the JFace JARs. SWT is a bit more complex because it contains one JAR per supported platform; you can find the JARs for all platforms in the "Delta Pack" (download for Eclipse 4.2)
When writing your application, you will need to determine the platform and add the correct SWT JAR to your classpath. Here is the code to do that: Create cross platform Java SWT Application
Is it possible to create an extension or plugin for Eclipse that gives support to a specific language? Where i can find information about that? Also, can i repackage Eclipse, along with that plugin, and distribute the new package, just like PDT, for example?
Have a look at this page:
http://wiki.eclipse.org/The_Official_Eclipse_FAQs
There is a section "Implementing Support for Your Own Language" at the bottom of that page.
You should definitely have a look at Xtext which allows you quite easily to get first grade ide support for your own langage.
http://www.eclipse.org/Xtext/
It's possible. In fact support for specific languages is implemented as plug-ins. See eclipse platform plug-in developers guide and then search for details. Or look for some book like eclipse plugins.
You can repackage and distribute new package. In fact eclipse license gives you more freedom in this than for example GPL.
I'm currently working on a project which source code should be as portable as possible; that is, the project (in C#, but it is not very relevant) represent an application that should be executed on Android (with Mono-Android), on iPhone (with MonoTouch) and WinMobile (with official Compact Framework). Without going into details, the corresponding MSBuild solution consists of an independent-platform library (from a source code point of view, at least) which declare various interfaces and classes that represent an abstraction of each feature that is not common to the various platform (i.e. the UI). In addition, there are a corresponding library that specialize (for each platform) the "base library"; the effective application executable is a program that uses the abstraction and the common standard libraries.
Developing on WinMobile and Android is not really a problem: Mono-Android add-in can be installed on VS 2010, so both platforms can be handled with MS VS.
Initially the solution was created in VS, so the initial configuration and the related projects (Android and WinMobile) are automatically generated.
After that I've imported the solution in MonoDevelop under Mac (the only platform that is officially supported by MonoTouch), and I've created the project for the iPhone library; switching the configuration to generate the assemblies (iPhoneSimulator) the "base library" was not possible to compile due to a missing project type configuration; specifically, the GUID used by MonoTouch for <ProjectTypeGuids> is {E613F3A2-FE9C-494F-B74E-F63BCB86FEA6}; adding this GUID I can now compile "base library" in MonoDevelop.
The problem arises when I try to re-import the solution in VS: since there's no Windows version of MonoTouch, VS cannot find the add-in for the specified project type, and the project doesn't load.
Looking to the specifications of MSBuild project file, it seems that there are tons of options that cannot be set or modified within the project/solution editor in VS; however the format is quite complicated and now I'm asking your help!
Is there a way to specify in the project file that a project type is present only if a particular configuration is selected independently to which is the environment I'm using?
The general approach is something like this; a condition that progressivly builds your property, referencing any value the property already may have:
<ProjectTypeGuids
Condition="'$(BuildingInsideVisualStudio)' != 'true'"
>;{E613F3A2-FE9C-494F-B74E-F63BCB86FEA6}"</ProjectTypeGuids>
<ProjectTypeGuids>{OTHER-GUIDS-HERE}$(ProjectTypeGuids)</ProjectTypeGuids>
This will detect the VS condition (when building) and omit the unkonwn guid. I'm not sure however if it will work when the project is opened, this property might only apply to building. There may be a similar "sentinal" property for building on Mono, and you can reverse the condition.
I solved an unrelated, but very similar issue of cross-platform development by excluding the files that presented themselves as cranky when going between Linux and Windows. I have my project under source control and utilized that to keep things working cooperatively.
http://www.aydabtudev.com/2011/05/what-goes-into-source-control-android.html
It's not a 1-to-1 for your issue, but it might give you clues/ideas on how to solve your problem.
just changed from Netbeans to Eclipse just for fun (Only developer on the company, So I can code on whatever and with whatever I feel like.) That's why I liked the new version of netBeans over vim, it could load resources or plugins, I am not quite aware of their naming conventions, on demand. For example if you were working on a Grails project it would only load grails related resources.
On Eclipse I have a gazillion plugins installed. Some to emulate Netbeans functionality (Grails, JavaFX, Ruby, PHP, CSS, Python, etc.) And some others Netbeans lacks (Android, Vaadin, SpringRoo, Git and some others) But I am not sure how Eclipse handles this plug in behemothing
Does it load them on demand? Do I have to manually disable the ones I am not using? Do I have to have different installs for each language I work on? Or do I have to learn how to live with this big mess of plugins in order to have everything I need at hand??
Thank you very much for your time.
Basically Eclipse loads the plug-in codes lazily. On the other hand, the menu/toolbar contributions are loaded at the start of the platform.
If the plug-ins are written correctly, they should not interfere with each other, and the unnecessary elements should be few in the context menus.
My suggestion is to try this installation, and look for potential problems. If you have problems with the environment, only then try to identify and remove the plug-ins. But it should be ok.