Prevent caching of Eclipse target definition - eclipse-pde

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.

Related

The project was not built due to "Could not delete ‘project’."

Firstly I take error given below:
An exception has been caught while processing the refactoring 'Delete Source'
After TFS cache is cleared, TFS server mapping is removed, .lock file in eclipse workspace .\metadata file is cleared, then TFS mapping is created, Get latest, Import is applied again and project can be deleted.After this, I pull project from TFS to my local path again in Problems view, error given below is taken:
The project was not built due to "Could not delete ‘project’.". Fix
the problem, then try refreshing this project and building it since it
may be inconsistent
Is my mapping can be incorret( Should I checked "Recursive" while setting mapping path)?
Thanks friends!
This Team Explorer Everywhere plugin enables using Team Foundation Version Control (TFVC) within Eclipse. And it is no longer maintained. It works on the operating system of your choice with Eclipse 4.2 (Juno) - 4.6 (Neon) as described here.
If you are still using this plugin, please follow this doc: Importing Projects from Team Foundation Server to import a project from the server to your Eclipse workspace rather than manually mapping and getting files. Manual mapping and getting is error-prone and can cause unpredictable behavior if you did not choose the correct mappings. Instead, importing can check compatibility issues and prevent Eclipse workspace problems.
In addition, for this particular eclipse issue: “The project was not built due to “Could not delete ‘project’.””, it seems that it is because customer has the workspace in a dropbox sysncing folder like this thread answered.

Is there any method to clean old plugins/features from disk automatically once new plugin/features are installed in eclipse RCP?

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?

WSO2 Eclipse plugin not working well

I'm using:
Eclipse Kepler
WSO2 Developer Studio v3.2 plugin
WSO2 esb v4.7.0
Maven 3.x
Java 1.7.x
Windows 7
And I'm having the following problems in Eclipse when using WSO2 Development Studio:
if I try to edit a file (via Design or Source view), the changes are not saved and are reverted back to the original values.
when I add a new Registry Resource to my Registry project, this resource is not added to the carbon file.
by deleting a resource file, the resource still exists in the project/Registry(path) and is not cleaned up well. I have to delete it manually from artifact.xml.
when I try to make a carbon file by running 'mvn clean install' from the command line, the build hangs. I've fixed this by changing the version of 'maven-car-plugin, wso2-esb-proxy-plugin, wso2-general-project-plugin' to 2.0.5 (default: 2.0.4).
And changes made to pom files are also not saved, they always revert back to original values.
Are these problems known and is there any solution available ?
Thx in advance and looking forward for a reply.
First of all I need to emphasize that WSO2 Dev Studio 3.2.0 is not tested and verified with Eclipse Kepler and the officially supported Eclipse version is Eclipse Juno SR2. Even-though Kepler is not tested, I do expect most of the features to work.
Following are the answers for your comments/questions:
Q.if I try to edit a file (via Design or Source view), the changes are
not saved and are reverted back to the original values.
Ans: What is the file you are referring here? Is it an artifact file? or an utility file such as pom.xml?
We have not come across this issue before that values are being reverted back to previous. However there is a known behavior that if you try to add a new element/value that is not being recognized by the ESB Editor, it will simply drop the newly added value from the source.But that behavior is specific to ESB Graphical Editor. Without knowing the type of file you are referring, I cannot 100% be sure what is going on.
Q. when I add a new Registry Resource to my Registry project, this
resource is not added to the carbon file.
Ans: Yes, That is the expected behavior. Rationale is that, In a given workspace there can be multiple C-App Projects existing at the same time. So we are not sure to which C-App project user wishes to include a given registry Resource. Adding the same registry resource or any other artifact to all the C-App projects does not seem right. Therefore we do not automatically include a Registry Resource or any other artifact in to C-App projects.
Another special scenario with Registry Resources is that, you can deploy a Registry Resource to any Carbon Server. Therefore we cannot 100% be sure about the correct Server Role for the Registry Resource.
After considering all the above facts we have decided not to include any artifact in to C-App Project and let users to add them.
Q. by deleting a resource file, the resource still exists in the
project/Registry(path) and is not cleaned up well. I have to delete
it manually from artifact.xml.
Ans: This could be due to a bug in the Refactoring component in Dev Studio. However we have done some modifications to the refactor components to improve it and fix some bugs in it for Developer Studio 3.3.0 Alpha 3 version. With those fixes, most of such issues will go away.
Q. when I try to make a carbon file by running 'mvn clean install' from
the command line, the build hangs. I've fixed this by changing the
version of 'maven-car-plugin, wso2-esb-proxy-plugin,
wso2-general-project-plugin' to 2.0.5 (default: 2.0.4).
Ans: There was serious a performance issue related to wso2-general-project-plugin and wso2 esb artifact plugins released with Developer Studio 3.2.0. We have identified this issue [1] and fixed in the latest versions of the plugins as you have discovered. So with those plugins, you will experience a greater performance improvements.
Q. changes made to pom files are also not saved, they always revert back to original values.
Ans: There is a known issue with updating properties section of the pom.xml of C-App project [2] and we are working on fixing this for the upcoming Dev Studio release.
Hope this clarifies some of the concerns you have and provide answers to your queries.
Thanks and Regards,
Harshana

Programatically installing an Eclipse plugin from within Eclipse?

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.

Modifying Existing Eclipse Plugin and Correctly Installing it

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 .