Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #335153 +++ Build ID: eclipse-platform-4.3M7-win32-x86_64 1. Download org.eclipse.tm.repo.zip from a recent TM Hudson Build https://hudson.eclipse.org/hudson/job/tm-master-nightly 2. Launch Eclipse, add the archive, install RSE Runtime --> Some bundles are warned as being unsigned, because they are downloaded from the remote Kepler simrel repo - although all the dependencies are available in the downloaded local org.eclipse.tm.repo.zip (as can be verified by installing with Kepler disabled). I find the behavior of downloading / installing remote content even when local content is available highly confusing. It adds unnecessary network load, may cause timeouts or incomplete downloads, and makes things nondeterministic when the remote mirrors don't have perfect content. It is very possible that some of the confusing recent problems with the Eclipse Platform build, or the EPP build containing different binary bits than Platform, are related to this. I expect that when I give complete local artifacts to p2, these are used with priority. I had thought that this problem were fixed with bug 335153 but now this problem reappears. Please let us know the thinking of the p2 team !
On a related note, this behavior of p2 can also lead to unexpected contents being downloaded, when version ranges are not very strict. In this case: The TM/RSE ftp support can work with commons.net_2.0 or later so that's the dependency we have in our MANIFEST.MF and feature.xml. For years, we've been bundling commons_net 2.2 but now we want to upgrade to commons_net 3.2. Thus commons_net 3.2 is what we have in our downloaded tm.repo.zip. But when I initially installed with the Kepler Repo enabled, I got _both_ commons_net 2.2 and commons_net 3.2 installed. This isn't a problem with commons_net but having followed recent discussions around Guava and other libraries, having too many versions of a lib installed may cause severe issues. Requesting tighter version ranges from the projects is one way of dealing with this, but I'm not sure if it's the right way. Again the minimum that I expect is that if I - as a product builder - pass in a set of downloaded artifacts, I expect these to be treated with priority, in a deterministic way.
Please reopen with a reproducible scenario if this problem is still current in the latest release.
