I am building an RCP application, where there will be updates in the features/plugins every quarter. So, if a user chooses to auto update the feature/plugin then new jars for updated plugins are getting downloaded, but the old plugins are still using my disk space which are no more in use.
I have tired deleting the installation history which has the information of old jar. While I try to delete it, it shows me the below given message
But this does not delete the .jar, I can still find it in my feature/plugin folder.
Also, this is a manual process. So, is there any way where the old plugins gets deleted automatically when there is new jars with updated version.
Enable the p2 garbage collector in your plugin_customization.ini file as follows for that:
# after upgrading delete the plug-ins that are no longer needed
org.eclipse.equinox.p2.ui.sdk.scheduler/gcOnStartup=true
For details see the Eclipse wiki: Equinox p2 FAQ - Why aren't bundles being removed when their associated feature has been removed?
Related
I'm using a target definition that references a P2 update site.
Update site was updated recently with a plugin that has same version and qualifier as previous version, but different content.
I've deleted .metadata/.plugins/org.eclipse.pde.core and tried resolving and applying target definition again. Strangely, target definition recreates previous version of plugin in .metadata.plugins\org.eclipse.pde.core.bundle_pool (I'm checking its content and behaviour)
Where could the content be cached and how do I flush this cache?
Version: Kepler Service Release 2
Build id: 20140224-0627
Update site was updated recently with a plugin that has same version and qualifier as previous version, but different content.
Well in this case you have a problem.
This kind of changes violates the most basic assumptions of p2, and hence you cannot expect anything to work correctly any more.
P2 stores "global" cache outside workspace or Eclipse installation in user's home directory:
$HOME/.p2/pool
Once that is wiped problem is solved.
Unfortunately, this folder is used by all Eclipse instances installed with Oomph (Eclipse Installer), and its removal will make them unusable.
Note, that removal of some plugins from that folder will corrupt index integrity and will also make all of your Eclipse installations unusable.
I am trying to deploy a version of Eclipse and would like control over the default repository list. See my earlier question.
In my other question, I learned that this is stored in the user's home directory under ".eclipse\org.eclipse.platform_3.7.0_525061626\p2\org.eclipse.equinox.p2.engine\profileRegistry\epp.package.cpp.profile\.data\.settings\org.eclipse.equinox.p2.metadata.repository.prefs".
I would rather not deploy this file to a user specific location because there might already be one from another Eclipse installation and there could be more than one user account.
Is there any way that I can avoid the user profile?
I did find an equivelent file under the main Eclipse folder "eclipse\p2\org.eclipse.equinox.p2.engine\profileRegistry\epp.package.cpp.profile\.data\.settings\org.eclipse.equinox.p2.metadata.repository.prefs" but changing this didn't make any difference.
Thanks,
Alan
You can use p2 touchpoints and the p2 director to install your feature to customize the version of eclipse you are trying to deploy.
See p2.inf for an example of touchpoint configuration instructions that add p2 repositories to the default install. This one is part of an sdk.product generation. If you are starting with an eclipse that already has a product, your touchpoint instructions would have to remove the repositories that were already included and then add your own.
instructions.configure=\
addRepository(type:0,location:http${#58}//download.eclipse.org/eclipse/updates/3.8,name:The Eclipse Project Updates);\
addRepository(type:1,location:http${#58}//download.eclipse.org/eclipse/updates/3.8,name:The Eclipse Project Updates);\
addRepository(type:0,location:http${#58}//download.eclipse.org/releases/juno,name:Juno);\
addRepository(type:1,location:http${#58}//download.eclipse.org/releases/juno,name:Juno);
The way that I ended up doing this was to create a lightweight plugin that starts when Eclipse loads. This then programatically adds the update site as detailed here: https://stackoverflow.com/a/7384954/101642
I need to configure my eclipse product to load all features/plugins in features/plugins directory. Now my product loads just plugins that are listed in metadata, so if I export some plugin directly from eclipse tool as "deployable plugins" it's loaded in my product, but if I put a plugin jar directly in plugins directory It doesn't appear (the same if I work with features)
I simply make new product configurations, put the feature that contains my application plugin and then exporting product I have this problem.
My eclipse version is 3.6.1
I think the problem is in the launcher configuration but I don't know what I have to change
In theory, your exported RCP application should simply pick up any new features and plugins you add later. However, make sure you put the extra stuff in the dropins folder of your RCP, since this is the expected location for manually installed features since the introduction of p2.
If for some reason it still doesn't work, try launching Eclipse with the -clean command line argument.
According to The Eclipse runtime options page, the -clean argument has the following effect:
[...] any cached data used by the OSGi framework and eclipse runtime will be wiped clean. This will clean the caches used to store bundle dependency resolution and eclipse extension registry data. Using this option will force eclipse to reinitialize these caches.
In my experience this can resolve many mysterious cases, where newly added plugins are not loaded by Equinox.
I want to create an automated installer for an Eclipse plugin (i.e. not through the "Update Manager"). My scenario is simple: the user closes Eclipse, drops a downloaded JAR into the dropins folder, starts Eclipse and the rest of the process is automated.
In older Eclipse versions, before the era of P2, Eclipse had (still has) a class called InstallCommand which could be used to install pluings into the currently running platform.
While this still works in Eclipse 3.4 & 3.5, it is not behaving properly: most noticeably, plugins installed that way cannot be automatically uninstalled (it is dimmed).
The JavaDoc claims the InstallCommand is deprecated and should be replaced by a P2 alternative. However, I couldn't find the right tool for the job. There is the P2 director, but it is built for running as a separate application from the command line. It is possible to invoke it from within Eclipse but it is really not cut out for that. For example, progress monitoring and error reporting are not working well.
Does anybody know of a good alternative for that?
Thanks,
Zviki
Dropins seems very close to what you want, especially if they are just downloading jars without the associated metadata (ie the metadata will need to be auto-generated).
You could consider defining a second dropins area to manage yourself. Take a look at ProfileSynchronizer in org.eclipse.equinox.p2.reconciler.dropins, in particular the method createProfileChangeRequest. I expect the uninstall behaviour you don't like is a result of the IInstallableUnit.PROP_PROFILE_LOCKED_IU property being added.
The dropins are reconciled at startup, see the p2.reconciler.dropins Activator.watchDropins(), you can likely do the same from your own bundle to watch another folder.
I suggest to deploy your plugin as an executable JAR. The installer in the JAR should ask for the Eclipse install directory and unpack the plugin in the right place (plus some more checks as needed).
Optionally include a little "watchdog" plugin which doesn't depend on much and just checks that your main plugin loads correctly and displays a useful error message which the user can email to you for support.
According to information in bug 311590 1 which is referenced in the deprecation comment of InstallCommand an alternative is possibly to use P2 operations 2, 3.
I downloaded the source code for the EMF based UML2 Plugin and changed a class in the org.eclipse.uml2.uml.edit project to remove special characters when returning string representations. Now when I export the projects and place the jar files either in the dropins directory or replace my current uml2 plugin jar files in plugins directory, The UML files are no longer recognized, in short my modified plugin does not install correctly (no error is thrown and I can see the files being picked up under Plugins->Target Platform) .
However, When I run the plugin as an eclipse application (from the workspace) I can see the changes I made being reflected in the new instance of eclipse.
What can I do to ensure that the plugin installs correctly?
Is there a documented procedure of how to build the uml2 plugin (or any comparable plugin) after modification?
Select the project and open the context menu. There is an entry PDE near the bottom of the menu. In there, you can find an entry to build the plugin for deployment. This gives you the features and plugins directory with the fixed files. Copy both into your Eclipse install.
Unless the UML2 plugins require some kind of magic build script, exporting the one plugin you changed and overwriting the original in your Eclipse installation should be the easiest solution. One potential problem which comes to mind is conflicting plugin version numbers: make sure you don't have two identical versions of your modified plugin in your Eclipse installation.
When debugging plugins which apparently don't work properly at runtime, I always look at Help > About Eclipse Platform > Configuration Details. This lists all the plugins found by Equinox during startup, along with their status (see the Javadoc of the org.osgi.framework.Bundle interface for explanation).
I faced the exact same problem as you describe here . I dont have any answer to your problem but i am sharing what worked for me .
I created a local update site of the plugin on my system. Create update site for your plug-in article explains very very nicely the steps needed to accomplish this .