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.
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.
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.
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.
来源：https://stackoverflow.com/questions/12641464/eclipse-does-not-download-latest-jar-of-the-same-version-from-the-target-platfor