Community
Participate
Working Groups
Build Identifier: Installed 64 bit eclipse product as Admin and launched the product as Admin. Switched to regular user and launched the product and installed other eclipse plugins. Eclpse plugins installed fine but when re-started the product after installing, eclipse plugins was not loaded. Note that when installing eclipse plugins as admin, it loads fine. Also the issue doesn't occur in the 32 bit . It occurs with 64 bit when installing eclipse plugins as non-admin. Reproducible: Always Steps to Reproduce: 1.Installed 64 bit eclipse product as Admin and launched the product as Admin. Switched to regular user and launched the product and installed other eclipse plugins 2.Eclpse plugins installed fine but when re-started the product after installing, eclipse plugins was not loaded. 3.
This works fine for me with the latest SDK Build. Please include additional information so we can try and reproduce the problem. Thanks.
I am now able to re-produce the problem with the product-based install. This is similar to the scenario described in bug 322056 comment 7. The bundles are the same in the bundles.info files but the file locations are different (different relative path calculation) so the system believes that the user's bundles.info does not contain all the bundles from the shared location, so it reverts to running the bundles from the shared bundles.info. This results in p2 believing that it has something installed (it is in the profile registry, About dialog) but OSGi doesn't think it is installed (it is not in the particular bundles.info we are starting from).
This problem stems from the fact that the product has the equinox.launcher JARs in 2 locations... in the plugins folder co-located with the exe and also in the shared bundle pool. Because there are 2 copies of the JAR files and each location is considered a repository, the JAR file is available from 2 repositories. So later on we ask for the JAR file and we happen to choose a different one than expected. I believe this is related to the cache extensions property and the order of the repositories. In bug 246310 we introduced a sort order in ProfileSynchronizer#synchronizeCacheExtensions so the OSGi install folder would be the first in the list. Later on in the Eclipse touchpoint Util#getAggregatedBundleRepository we iterate over the repositories and return the first location we find it in. The problem that we are seeing now is that the OSGi Install Location that we are using for the compare in the array sort, is returned to us by OSGi as an unencoded URL and we are comparing it against repository locations which are URIs. (and therefore characters like spaces are encoded) So in the current code the repository locations look like: C:/Program%20Files/Product but the OSGi install folder looks like: C:/Program Files/Product so it isn't taken into consideration and the repositories are sorted in lexicographical order. Thus when comparing: C:/Program%20Files/Product and: C:/Program%20Files%20(x86)/Product the second one is returned first.
Created attachment 197171 [details] patch Patch which converts the OSGi install folder property to an encoded URI so we can correctly compare it to the repository location URIs.
Patch released to HEAD. (along with manifest bundle version update)
