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.

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.

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.