I have created a RCP Application. Currently it is using org.eclipse.swt.win32.win32.x86_64_3.107.0.v20180611-0422.jar. I have a lastest version of SWT jar(V3.11) which I want to add it to plug-in dependencies.
How do I do it?
PS : I'm using Photon version of eclipse.
You don't need to do anything to the plug-in. The choice of dependency plug-in versions is done automatically using the plug-ins in the "Target Platform" that you are using. The versions shown are the plug-ins in your current target platform. You change to a different set of plug-in versions by defining a target platform in the Preferences in 'Plug-in Development > Target Platform' and making that target active.
The 'Require-Bundle' entry in the plug-in's MANIFEST.MF can specify a range of versions which are allowed for the dependency.
So
Require-Bundle: org.eclipse.e4.ui.di;bundle-version="0.10.1"
says that at least version '0.10.1' of the 'org.eclipse.e4.ui.di' is required.
Related
I'm developing an Eclipse RCP application with Eclipse 4.4 Luna M5 and I'm using Guice 3.0.
So I added guice.jar to my target platform and for every plug-in I'm developing I can add bundle com.google.inject to the plug-in's dependencies using the plug-in manifest editor of Eclipse. So far, everything works fine.
Now the problem: I want to use guice assisted injects (#Assisted).
So I added guice-assistedinject.jar to my target platform. (I'm using a .target file = Eclipse Target definition file).
In then "Content" tab of the .target file editor Eclipse correctly shows me the fragment bundle com.google.inject.assistinject 3.0 from guice-assistedinject.jar, but I cannot add this bundle or an exported package of this bundle to the dependencies of the plug-in projects I'm developing.
When I press "Add" in the plug-in manifest editor, com.google.inject.assistedinject is not in the list of addable dependencies? What's wrong?
Here my comment as answer again:
OK, found the solution: it's a PDE problem, see accepted answer in Eclipse OSGi bundle reqiure another bundle's fragment
After changing the manifest of my guice-3.0.jar in the target platform like described in the link above, I needed to do the following:
Reload the target platform (Windows -> Preferences -> Plug-in development -> Target platform) and restart eclipse.
Remove the bundle com.google.inject from the required bundles of my plug-in.
Add all needed com.google.inject packages to "imported packages" of my plug-in. Now in the list of packages I can see com.google.inject.assistedinject.Assisted and import it!
I developed an Eclipse plug-in and installed it in Eclipse. After making some modifications in the plug-in source, I re-released that plugin in an Update Site. I tried to get the plug-in through "new software install menu" and re-install the plug-in in Eclipse, but the installed version of the plug-in is not the current version; it is the previous one. How can I adapt the current plug-in in Eclipse mantaining the plug-in version?
Did you update the version number of your feature before releasing it to the update site? Eclipse checks the version number, and only installs the new version if its version number is newer than the one already installed.
I'm developing an RCP project using Eclipse-Helios.
The version of SWT that is installed (in the plugins directory) is [org.eclipse.swt-win32-3.6.2, & org.eclipse.swt.jar]
I require new API functionality that is only available from swt-3.8. (specifically, I wish to set the custom colours, for an SWT color dialog before opening.)
I have downloaded 3.8.1 from the SWT/Eclipse downloads site [ http://download.eclipse.org/eclipse/downloads/drops/R-3.8-201206081200/#SWT ]
The SWT download is NOT a plugin (couple of jars, src.zip and some readme files), so I am unable to add it to my "Target Platform" (it doesn't appear as an available jar even after adding the containing directory in "locations")
I was unable to find an update site for SWT (or any site where i could get a plugin for the newer version)
If I add the swt.3.8.jar to my classpath (and then increase it's order-priority in the project build-path), I am able to access the newer api functionality from my code (as well as view the source).
When I run the application however, it seems as though the runtime is still using the older SWT jar, as i get an unknown method error, when attempting to access the newer functionality.
Questions:
Is there an SWT repository location that I can use to download a newer version of SWT using the eclipse install manager?
If not, is there a way I can force the runtime to ignore the older version (I assume via plugin.xml)?
Is there a better way to achieve what I am trying to do?
What is the difference between the two SWT jars currently in the helios plugins directory (as the 3.8 download only contains the win-32 version)?
Thanks in advance.
SWT is downloadable as a separate plugin here:
http://download.eclipse.org/eclipse/downloads/drops/R-3.8-201206081200/#SWT
Eclipse 3.8 contains regular plugins including the SWT (the win32 specific as well as the generic "org.eclipse.swt_.jar"). I am currently using the 3.8 version and they appear as plugins.
I also have Eclipse 3.6 (Helios) and I was able to import the swt plugins using the "File->Import->Plug-in Development->Plug-ins and Fragments" wizard. I just specified the eclipse 3.8 directory and could import them in my workspace. Once imported I can of-course use them to be included in the runtime environment. Eclipse should use the latest version automatically.
Is there a way to build an Eclipse Update Site so that Eclipse 3.3 will install one version of my plug-in while Eclipse 3.4 will install another version? The feature spec allows for "optional included features" but I can't see how to make them conditional on the version of the target.
Background: I've become responsible for an Eclipse extension that has half a dozen plug-ins which depend on a "support" plug-in, and the support plug-in needs to be one version for Eclipse 3.3 and a different version for Eclipse 3.4/3.5. I currently have two separate features, "extension for 3.3" and "extension for 3.4+" but I'd like to not bother my users with this detail.
I have a plugin for an RCP app that uses BIRT. I have a target for building my app which contains only the plugins/features that are required. I recently updated the BIRT plugin versions in my IDE, which created an incompatibility in the design files with previous versions of BIRT. I have the old version of BIRT in my target and need to update to the newer plugins.
In the past I have manually updated plugin jars in the target, but BIRT is a complicated platform with dependencies out the wazoo. Is there any utility or way of organizing my target differently that will make this easier to control in the future?
I would recommend to keep all components separately and not copy them into a single folder. You can use Target Definition editor (see File / New / Other... / Target Definition). So, after downloading all the pieces, you can unpack them locally and assemble your Target Platform using Target Definition editor.
You can also do the same using Window / Preferences / Plugin Development / Target Platform preference page. There you can select previously created target definition or specify base Eclipse install and then use "Add..." button to add additional components from local folders or remote sites.
Also, as far as I know the PDE team is currently working on expanding Target platform support in Eclipse 3.5. I think they are planning to allow to select Target Definition per-launch configuration and per-project.
Im not sure if i understand you right, so please let me know if not.
When i use third party libraries, i create a plugin for every single one.
Example:
xstream library:
Import the jars (also the source code)
Add the jars to the MANIFEST
Bundle-ClassPath
Add all xtream packages to the
MANIFEST Export-Package
When a plugin needs the code of the xstream library it has to depend on the xtream plugin. Because the packages are public, every plugin can use the source code of it.
When a new version of xtream is comming, you only have to update the jars and not the dependend plugins. Sometimes you have to update the export packages of the third party plugin.
All depended plugins you dont have to change.