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.
Related
I want to distribute an eclipse platform with pre-installed plugins to different users with different operation systems.
On the side http://www.eclipse.org/downloads/ I have to choose the target platform for eclipse, so I downloaded it for Linux 32 and 64 bit and for windows 32 and 64 bit.
I want to distribute an eclipse with some pre-installed and also self written plugins to other people. Can I simply install the plugins in one eclipse installation and then copy the files from the /plugins folder to every /plugins folder of the other eclipse versions for linux and windows or are the plugins (also the pre-existing default plugins) in the /plugin folder also platform dependend and must be installed seperatly on the target platform?
Some are, some aren't. Eclipse supports the inclusion of native code in OSGi bundles, and then unpacks it and accesses it via JNI. The native code can be in separate 'fragments', and Eclipse won't necessarily download all the fragments for other architectures.
Well, here's the way I see it: Eclipse is written in Java, which is platform-independent. Eclipse's plugins are, therefor, written in Java, and must be platform-independent. Also, I've yet to encounter a plugin that wasn't platform-independent. So yes, to the best of my knowledge.
What is the best way to configure target platform to develop Eclipse RCP application? Download 'pure' Eclipse and add only needed plug-ins in project or download Eclipse for RCP and RAP Developers? And what is better solution to add plugins? Open Eclipse-TP and download from eclipse-marketplace or manually copy jars to appropriate folders?
It depends on the set of plug-ins your RCP application depends on.
"RCP SDK" provides a minimal target platform, with source code.
"Platform SDK" provided more plug-ins, with source code. It includes more plug-ins than RCP SDK, without including the developer-oriented plug-ins of Eclipse IDEs. Unfortunately, this platform is not currently provided.
"Platform Runtime Binary" provides the same thing as Platform SDK -- without source code.
If you want to release on multiple platforms, also download the DeltaPack, which contains platform-specific resources for multiple platforms.
By the way, if you're adding the target platform to version control, use binary type for the following files in plugins/*/META-INF:
eclipse.inf -- line endings should be NL
MANIFEST.MF, ECLIPSE_.SF, and ECLIPSEF.SF (note the spelling) -- line endings
should be CR/NL
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.
We have an Eclipse RCP product, which means it depends on a number of Eclipse plugins (for the UI etc). We have set up a reference Eclipse ("target") to supply the latter.
Our product also depends on a number of third party plugins. Is there a standard location for these to be put?
We have a few of our third-party plugins in the /plugins of the target Eclipse, but this seems wrong to me. The third party plugins change more frequently than, or at least in a different timeframe to, our reference Eclipse.
I tried putting some third party plugins in a separate project in the workspace (under version control), but the PDE headless build did not seem to find them - even though I used the pluginPath property in the headless build.properties.
This is Eclipse 3.4.2. I am aware than the handling of target platforms has changed somewhat in 3.5.
Most of the comments I've seen see on the web about this seem to assume that you're writing a plugin to be added to a standard Eclipse installation. We're not, it's a completely separate product.
For my RCP applications I created a customized target platform directory for it to use (e.g. rcpapptarget). Under that directory I unzip the following packages:
eclipse-RCP-SDK-3.4.2-win32.zip
eclipse-3.4.2-delta-pack.zip
Then I add what ever other eclipse or third party plug-ins that my application will need. For example:
the latest GEF all .zip file
jay libs EclipseCallBasic_1.1.0 plug-in
derby distributed plug-in
additional eclipse plug-ins needed for help support, cheatsheets, updates etc.
I then setup a workspace for developing that RCP application and point the workspace's "Target Platform" to use that customized target platform directory. I do all my development using that target platform and my headless builds use it too.
To set the target platform choose the Window | Preferences command and then select Plug-in Development | Target Platform from the preference tree. Set the "Location" to point to the directory you created.
There isn't a standard that I know of for where 3rd part plugins should go. You can define an external extension location and store your party plugins/features there. This also allows you to reuse the plugins in multiple Eclipse installs if you wish.
You add an Extension location by going to
Ganymede onwards: Help->Software Updates->Available Software->Add Site->Local
Older versions: Help->Software Updates->Manage Configuration->Add Extension Location
For Ganymede onwards, the extension locations work a bit differently (IIRC the plugins are copied to the standard Eclipse install, which kind of defeats the point),there is however a new concept called dropins that you might find useful.
In Eclipse (3.3) if you start the New Plugin Project Wizard, the first page has a Target Platform, where you can target a version of eclipse.
Is this information saved/used and if so where?
Also if you then create an extension the plugin.xml is created, and at the top is (for me) :
<?eclipse version="3.2"?>
Where did this version come from?, does it depend on the extension you just extended? Will it be updated/changed?
The plugin 3.2 version is there because there were changes prior to 3.2 which would make it incompatible. However, it's remained the same from 3.2 onwards.
You'll also find that it records the information in the MANIFEST.MF in the Required Execution Environment and (for OSGi apps) puts specific versions in the org.osgi.framework or org.eclipse.core dependencies.
So there's a subtle mapping between Eclipse version and what version numbers are put in these entires; it's not just a 1-1 correspondence between the two.
Some elements of answer:
From "Whats your Target?" (for Galileo 3.5, but some applies to 3.3)
The IDE is your workbench and the Target Platform defines your Product you’re creating using the IDE.
What do you need if you have to make your product run outside Eclipse ? (Equinox ? Logging ? Riena ? RAP ? Jetty ? )
On which platforms (OS) should my product run ? (Windows ? OSX ? )
In recent eclipse, the following are including in a Target definition:
the location of the target,
the list of plug-ins constituting the target (Require-bundle in the MANIFEST.MF),
the target environment (in plugin.xml)
launching argument
But the main information of a Target platform remain the list of plugins needed.
From "PDE Does Plugin":
In order for PDE to provide a development environment that is identical to the runtime environment in which the plug-in will be later deployed, one needs to specify the Target Platform.
Target platform refers to the set of plug-ins with which the plug-in being developed will be deployed. At runtime, most plug-ins require other plug-ins to be on their class path in order to run properly
From RCP FAQ:
PDE currently supports two versions back for plug-in development. That is, with Eclipse 3.2 you can develop 3.0 plugins and launch 3.0 systems, but not 2.1 or earlier.