I have a simple RCP Plugin (with a product) and I want it to run in atleast Linux and Windows (32 and 64bit). I have a product that contains a Feature from which buckminster uses to create the p2.site. (I only use a build.properties and buckminster.properties files, no *.cspec and *.rmap files, since these probably get generated by buckminster from the RCP product/feature files).
My problem is that my feature has a link to the 64bit linux swt plugin (I'm running 64bit linux) but if I add references to the windows swt plugins to my RCP .product the buckminster build fails to resolve these plugins and then does not export the p2.site correctly.
How do I get buckminster to build the p2 site by looking at the dependencies of my RCP .product file and if it doesn't resolve the win32 or win64 swt libraries from my workspace that it will look else where for these dependencies?
I like the idea of buckminster determining my project dependencies from my .product file so I don't have to keep a .cspec and a .product file in sync, when I make changes to my project's dependencies. If the dependencies are not found on my workspace then I want buckminster to find the missing dependencies (could be all of them if running from Hudson server) from "maybe" a .rmap etc
You have to execute your site.p2 target several times, to provide a build for each platform.
See the tutorial on the Eclipse wiki or on Ralf Ebert's blog about more specific details.
Related
I'm developing an Eclipse RCP application. The application should run on Windows and Linux.
There are several plugins in this application that contain native artifacts. To contain these artifacts in a binary build (jar), one should specify them in build.properties file.
Currently I include both Linux and Windows native artifacts in build.properties and then in runtime I choose which one to load. However, I don't like this approach as it causes unnecessary files to present in both Linux and Windows builds.
Is there a way to specify target platform in build.properties? So that for Linux build it would include Linux artifacts and for Windows build it would include Windows artifacts?
Alternatively, is there a way to maintain two copies of build.properties - one for Linux build and second for Windows build?
The usual way to do this is to have separate plugins (or plugin fragments) for each platform with a platform filter which restricts when the plugin is available:
For example, in the MANIFEST.MF
Eclipse-PlatformFilter: (& (osgi.ws=cocoa) (osgi.os=macosx) (osgi.arch=x86_64) )
restricts the plugin to only Mac OS X 64 bit, Cocoa.
This is what SWT does. There is a base org.eclipse.swt plugin which doesn't contain any code and then multiple plugin fragments extending that plugin (such as org.eclipse.swt.cocoa.macosx.x86_64). Each fragment contains the SWT code for a platform, all implementing the same classes.
Eclipse only loads the plugin for the current platform so you don't have to do any work choosing what to use.
I search some informations about the faisability of the exact inverse protocol described into this popular question.
Using SBT, i want to compile and/or generate a release of an already existing software actively developed with Eclipse and Plug-in Development Environment (PDE) of Eclipse.
Users want to conserve the eclipse GUI tools to define dependencies for each plugins. But we also need a console tool like SBT. Do you think it exists some tools which can generate an SBT project based on plug-in dependencies written using eclipse PDE systems ?
I see that tycho plugin for eclipse can generate maven file, is it possible using SBT and IVY repository ( don't want .pom :( ) ?
I am developing an Eclipse RCP product in Eclipse e4 environment using Kepler for RCP developers on 64-bit Linux and Java 7.
I'd like to use Eclipse Babel language packages within my Eclipse product. Copying features and plugins directory into Eclipse IDE directory works without a problem. I can run my Eclipse environment in the language I want by passing -nl argument.
I used PDE to produce a product and applied the same step by simply copying the language package into the product's features and plugins directory. However, it did not work as I see OK and Cancel button labels still in English.
Is it correct to simply copy the files or do I have to add an extra dependency?
Thanks.
I want to use two versions of ant plugin in eclipse for two different projects. Both versions are available in the plugins folder of my Eclipse. But I'm able to see only the latest version of ant plug-in when I'm trying to add it in the plug-in dependencies in Manifest.MF file. Please help me with this.
You can try to import both of ant plug-ins into your Eclipse workspace. Then you can let your projects depend on any version of ant for your development.
For building or releasing process, you can use Tycho to define a target platform to include both of them.
I have implemented a graph editor with Eclipse EMF and GMF frameworks. After completing my project, I realized that this plugin shows dependencies (not explicitly added by me) on some OS-specific plugins.i.e:org.eclipse.ui.win32, org.eclipse.swt.win32.win32.x86. And whenever I have tried to bypass this dependency at my update site something went wrong with the installation process of the plugin.
As such it is impossible to run my plugin in *nix environment or even win64 machines.This seems a very heavy constraint dependency to me. Am I doing something in a wrong way? Or is there no other way of building Eclipse plugins which are cross-platform other than building the project from scratch at each different OSs?
We created a similar style of plug-in in my project. Under "Plug-in Dependencies" in Package Explorer I can see org.eclipse.swt.win32 listed, but it is not listed in required plug-ins in plugin.xml.
We also successfully created an update site which works for Mac users without issue.
So, yes it is possible to have a cross-platform plug-in.
I would suggest you first try to to use "Export..." -> "Deployable plug-ins and fragments" to create a bunch of jar files for your plug-in. See if these can be successfully installed by copying into the drop-ins folder of a fresh eclipse installation. Do this first on a Win32 install, then try on another platform. Once you have that working, use the new Eclipse installation to create the Update site.