Eclipse does not download latest jar of the same version from the target platform

Question

I have a strange problem in our Eclipse IDE (Indigo V3.7.2). We use a target platform hosted on a server which is a p2 repository built using the b3 aggregation process. We get certain components and features from a different team. Every time they deliver the plugins, the version numbers remain the same (e.g myjar_v1.0.0.jar) (of-course the size is different). We update these plugins on the remote server. After this update, the problem is that, if I use an existing workspace, I see compilation issues in my code because of the latest jar not being downloaded from the target platform. Does eclipse not recognize the new plugin because of the same version and name? If yes, I tried removing the old jar from my workspace's .metadata folder, restarted eclipse, but still the problem persists. I deleted the entire .metadata folder itself, but still it did not help. Does eclipse share the plugins/jars between workspaces. i.e. If any of other workspace on the same machine has the same jar? We use maven for our builds. Does eclipse refer to the plugin from the local maven repo? Does eclipse maintain cache of the data from the target platform? If yes, where?

This problem is actually driving me crazy and I need to find out a way to use the latest version of the jar eventhough the version number is same. (We do not have much control on the other team versioning method)

Any inputs will be greatly appreciated.

Kingsbury

In a bundle pool: https://mcmap.net/q/1775581/-prevent-caching-of-eclipse-target-definition – Maseru

Answer 1

Eclipse (well p2 actually) uses the ID + Version as the unique identifier for a bundle. This is stored in caches and sometimes even shared between instances. If you change the content of a jar, even slightly, you MUST Change the version number. You'll notice that Eclipse uses version numbers such as x.y.z.qualifier where qualifier is a timetstamp (20120928-2359).

The MD5s that p2 has are only for checking validity of the download.

I'm sorry, but this is the way it is. Luckily, both Tycho and PDE/Build can handle .qualifier and change them into a meaningful date for you.

Tang

Thank you irbull for your inputs. However, how can I figure out where eclipse stores/maintains this cache and how/where actually these jars are shared between instances? – Kingsbury

Answer 2

I know this question is quite old, but perhaps I can give an insight into this problem.

Eclipse does not really share bundle pools between workspaces. Instead, all known workspaces are taken into account when resolving the target platform. These "known workspaces" simply are the ones in your "Recent workspaces" list. So, during resolution of a target platform in workspace A, Eclipse looks for needed bundles in the bundle pools of other workspaces and simply copies those already downloaded bundles from there to the bundle pool of workspace A, instead of really downloading the most recent bundle file from the P2 repositories configured in your target platform for workspace A.

The root of all evil is, of course, what irbull has already explained.

As a workaround, you can simply remove all other workspaces from the list of "Recent workspaces", close Eclipse, delete the bundle pool of the workspace you want to update, start Eclipse and initiate a resolution of the target platform of your choice. Eclipse will then really download all the bundles from the appropriate locations.

Mccullough

Answer 3

After many hours struggling with the Eclipse target editor, I've figured out some dance steps that allow me to manage my P2 repos and .target files. Nearly all of my headaches were caused by cache invalidation issues. I'm very good about ensuring that feature and plugin versions change when any code changes (see Tip 3 below), so the target should be picking up new versions, but many/most times it doesn't. Especially when I'm using local P2 repos. Why are local repos cached?

If the target editor doesn't find a new version of a feature or plugin, and, instead, persists in loading a cached old version of feature or plugin from the repository, you'll need to use the reload option in the 'Available Software Sites' dialog works invalidate the cache. But there are two versions of that dialog.

Plan A: If you only use remote (http) P2 repositories then these instructions should work: https://eclipsesource.com/blogs/2012/08/31/reloading-your-p2-cache/

Plan B: But if you use a combination of remote and local (file: URI) P2 repositories, you'll need to invalidate the cache using a more circuitous route.

1. Click 'Add..." in the Target Definition page of the Target Editor.

2. Select 'Software Site', hit Next. Click the 'Manage' button in the upper right.

3. In the 'Available Software Sites' dialog, select the repository you want to invalidate the cache for and click 'Reload'.

4. Return to the target editor, canceling both dialogs you opened, then select the repo whose cache you just invalidated and click 'Update'.

If anyone knows a faster path to this dialog that includes local repos, please comment.

Tip 1: For Target editor's 'Update' and 'Reload' to at least partially work, the artifact version should be set to '0.0.0' for lazy resolution.

Tip 2. If you do much target management, I strongly recommend M. Barbero's free and powerful Target Platform Definition DSL plugin. It generates the .target files for you, eliminating most all the hassles with feature and plugin versioning in the .target file -- and helps avoids having to use the embarrassing Eclipse Target Editor. To eliminate more version discovery headaches strongly consider using the 'lazy' option for each feature and/or plugin. The installation instructions are here: https://github.com/eclipse-cbi/targetplatform-dsl

And a good overview is here: https://eclipsesource.com/blogs/2018/05/30/eclipse-target-platform-definition-dsl-and-generator/

Tip 3: Install and use Eike Stepper and Ed Merks' Oomph version control for the PDE. Huge timesaver and keeps you out of the version control penalty box. It comes standard with Eclipse now. It will watch for code changes in any project you enable it for, understands the relationships between features and plugins, notifies you of projects that are not under version control but should be, flags the stale version numbers in plugin and feature manifests for updates and more. It even suggests the right major/minor version numbers based on the kind of change you made. https://www.eclipse.org/forums/index.php/t/1100576/

Vintner

Answer 4

I came across a similar problem and my Google Search led me to this page.

I figured I'd put in my answer here, in case it helps others.

Please Note (and as others have mentioned): This is not normal behavior to have the same numbered JAR if it is indeed different. I came across this because I had a "test" repository to make sure I could download a custom plugin from the repo, and I updated with the same version number, since once it becomes "official" in my company, that will be the version number it will use.

Long story short, I uninstalled my plugin through eclipse, removed the folder containing the plugin in my plugins directory, took the jar from the remote repo, and extracted it into my plugins directory, went back into Eclipse and installed my plugin.

Again, note that this is not the intended way to do this, and should be treated as a last-resort hack, since I don't know what other internal Eclipse assumptions this may break. I haven't seen any personally, but YMMV. If I come across any issues, I will update this answer.

Cropeared