How to provide Issue fixes, release update of eclipse RCP application, My Application having 200+ plugin and product is configured as a plugin not the feature.
I am newbie for RCP p2 update so having couple of questions.
Can I use equinox p2 update feature to provide update for plug-in, because most of all blogs given example with feature only and my product configured as plug-in.
Is there any way to update plugin version automatically, let say I have fixed some bugs due to which 2-3 plug-in are modified so need to change the version of this plug-in manually
And also need to update other plug-in which depend of this updated plug-in. So should i provide
version range in dependencies?
Which plug-in pick-up if two version are present, let say I have plug-in my-console.1.0.0.jar and then i have fixed some issue and updated the version to my-console.1.0.1.jar, now if user take the update then which plug-in version will get picked ? Its depending upon latest version or with timestamp ?
What if I deleted some plug-in, how this is get deleted using p2 update.
Also need some good resource of how patch fix, release updated notification given to RCP application user, How p2 central repository created, Standard guideline of Issue fixes, release update through p2.
Related
Earlier eclipse rcp workspace is referring to the target having log4j1.2.15 version. Below are the reference links.
eclipse latest p2 repository:(does not have the log4j)
ref1:https://download.eclipse.org/eclipse/updates/4.17-I-builds/I20200817-0920/plugins/
p2 repo with log4j 12.15 version
ref2:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2020-06/http___download.eclipse.org_releases_2020-06_202006171000/org.apache.log4j_1.2.15.v201012070815.html
From which p2 repository , we can find the log4j2 version jars (log4j2xapi, log4j2xcore).
Or is there any way to build jars and update corporate p2 repo instead of eclipse p2 repo
You use an integration (a kind of nightly build) repository for the future release, which will be deleted one day. If you don't want to test upfront whether your application will work with the future Eclipse release, better use a release repository instead.
Anyway, use the Eclipse project (the Eclipse platform and JDT) repository and if something is missing, check out the more comprehensive simultaneous release repository. If it is missing there as well, see if you can find it in Eclipse Orbit:
Eclipse Project: https://download.eclipse.org/eclipse/updates/<eclipse-platform-version>/ (currently, the Eclipse platform version of the current release is 4.16 and of the upcoming release is 4.17)
Simultaneous Release: https://download.eclipse.org/releases/<release-name>/ (currently, the current release is 2020-06 and the upcoming release is 2020-09) - in your case, also the repository for the upcoming release currently contains log4j
Eclipse Orbit
While trying to generate build we get some plugin dependencies. When trying to add them in .product file, It shows plugin version as 0.0.0 by default. We have a situation to add more than one version of same plugins.
We tried to manually change 0.0.0 to the required version from the dependencies. We are successfully able to launch the application. But while trying to generate a build we get some errors.We have the required plugins installed.
If anyone knows how to add different versions, the help is much appreciated.
Edit:
Image showing the problem
This is the problem we are facing
The solution we tried
We tried manually changing version number but creates error during build generation
I'm not sure that this scenario is supported by PDE Build, because it sounds exotic a bit.
You can try to use different features to introduce different version of bundle.
But I think that more promissing strategy will be to "align" your dependencies, i.e. in your case it is better to select the version of GMF that uses the right Batik version.
Otherwise sooner or later you will get "blocking" bundle with singleton:true in your dependency tree, as #greg-449 mentioned.
Also, please have a look at this question: Tycho | How to build multiple version of same plugin using tycho
See my answer there:
https://stackoverflow.com/a/62426443/9062163
In fact the details I mentioned in my other answer where the result of a successful integration of Sirius 6.0.1 in an Eclipse RCP based on Photon. The troubles came from the integration of Batik 1.7 and 1.6 in the same product, the latter version being forced by the GMF version I use. I also needed some batik plugins of versions 1.8.0 and 1.9.1 for other reasons.
We upgraded one of our Eclipse 3.x plugins to work with Java 9.
But when we generated the plugin update site content, and used Eclipse Update functionality to install the new version of the plugin, we encountered the following error in Eclipse Oxygen.
Removing part descriptor with the 'pluginxxx.bla.bla' id and the 'bla bla' description. Points to the invalid 'bundleclass://org.eclipse.ui.workbench/org.eclipse.ui.internal.e4.compatibility.CompatibilityView' class.
This error also appears due to some of the bundled plugins of Eclipse Oxygen itself.
After a hard week we had to
Uninstall our plugin
Remove the older versions of the plugin from the Eclipse/plugins folder
Export the plugin as a deployable plugin under the eclipse plugins directory. (Eclipse/plugins/blabla.jar)
Restart Eclipse and it worked.
Right click the eclipse plugin project and Run as "Eclipse Application" works fine, but installing the plugin from an "Update Site" causes the plugin to fail loading.
We could not find a solution yet, but it certainly effects our delivery of the plugin. The plugin is used by almost 500 CS students on their personal computers, and 200 lab computers. So the update should be installed using regular Eclipse Update functionality, not by copying the jar into the plugins directory.
Was there a better way to fix this, or something quicker we could've tried (in case this happens again)?
Update (7 days into the problem)
We have a workaround:
Export the feature project with the following settings in the Export Wizard
Destination/ Directory: Folder of your Plugin Update Site project
Options/ Package as individual JAR archieves (selected)
Options/ Generate p2 repository (selected)
Options/ Allow for binary cycles in target platform (selected)
Options/ Use class files compiled in the workspace (essentially selected)
Install (or update) the plugin from the local (or remote) plugin update site, and the CompatibilityView problem is solved.
In order to have the category listing displayed correctly during install/update new software operations, we added a category.xml file (File/New/Other/Plugin-in Development/Category Definition) in the update site project, defined the categories, and added the feature (versioned as "qualifier").
This is certainly not the way it should be, and we just hope it will be solved in the future Eclipse releases.
By the way current Eclipse Photon integration version has the same problem unfortunately.
I have an Eclipse Feature that I'm building that contains a few plugins. One of the plugins uses the import package statement to declare a dependency on another plugin.
The other plugin has platform specific code and exists in another feature that I'm building. I have two plugins in this feature that have the platform specific code. One for os=win32 arch=x86 and the other for os=win32 arch=x86_64
Both features are being built and using Tycho and they both have p2 repositories that are successfully available.
So, I made a composite repository that points to both of these repositories, and then I use the "Install New Software..." command in my RCP app and point to the composite repository to install the first feature I mentioned.
The issue is that when the installation is done, the plugin that has the platform specific code has failed to install correctly. Specifically, the plugin for the x86 system shows up on my 64bit machine.
In your feature.xml, choose the plugin with platform specific code and add a platform filter. the filters are available on the right side (once you select the plugin). You can choose filters such as:
OS
WS
Language
Architecture
When your feature is published, p2 will generate the appropriate filters.
I found the answer.
I needed a p2.inf file sitting next to my feature.xml file in the first feature I mentioned in the question.
And in that p2.inf file, I needed this text...
requires.1.namespace=org.eclipse.equinox.p2.iu
requires.1.name=com.myplatform.specfic.bundle.win32.x86
requires.1.filter=(&(osgi.os=win32) (osgi.arch=x86))
requires.1.namespace=org.eclipse.equinox.p2.iu
requires.1.name=com.myplatform.specfic.bundle.win32.x86_64
requires.1.filter=(&(osgi.os=win32) (osgi.arch=x86_64))
I added this file to the build.properties as well to make sure it was included in the deployed feature
Then when I deployed the p2 repository and performed the install into my RCP application, the correct plugin was placed onto my 64 bit machine.
UPDATE: I was wrong here. This is NOT the correct answer. The incorrect plugin still gets installed on some machines.
I am using Eclipse Helios 3.6
Eclipse Java EE IDE for Web Developers.
Version: Helios Service Release 1
Build id: 20100917-0705
I have a preferences page plug-in which sets a path which I need for my application. When I un-install my plug-in, the set path still remains in memory. I am fetching the value of the path I set from getTextControl().getText(), this returns the previously set value.
I read in How to clear data in Preference Store when uninstalling an Eclipse plugin? , that you need to use IProvisioningEventBus. I don't have much of an idea how this can be used. I'd be grateful, if anyone could provide a little more elaborate answer or if there is another way to clear the old value.
Thanks
Try running eclipse from the command line with the -clean flag.