Community
Participate
Working Groups
If a root feature “includes” another feature for the purpose of blocking its updates, then it should not be possible to update the inner feature using the update manager perspectives. (note: there is a separate pr indicating that tying inclusion and support availability together is a problem)
For V5 we are structuring our features to ensure that customers do not get updates from any lower level features. It is critical they not be able to circumvent this by going to the update manager perspective.
I have put together a design note with a proposed 2.0.1 approach for this and several related defects. See the doc below (have to paste the split line together to get the whole url). http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-update- home/doc/feature_extensions.html
Sorry, got the url wrong http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-update- home/doc/working/feature_extensions.html
There are two levels of defence here, and we don't know how strict to be: 1) Users can go into the Update Manager and install a new version of Eclipse SDK. A product that includes an older version will continue to be active, but at runtime the newer version will 'win' due to the behavior of the Eclipse registry resolver. The net effect would be that the Eclipse-based product now runs with the version of the platform it was not originally installed with. We can fairly easily prevent this if the feature is marked as to prohibit it (see Vlad's proposal). 2) Users can download newer Eclipse manually, unzip it, and copy plug-ins from the /plugins directory into the /plugins directory of the Eclipse-based product. We will not see anything strange but registry resolver will pick the newer plug- ins. 3) The same as 2), but the user also manually copies /features from the new Eclipse drop into the /features of the Eclipse product. On startup, Update will detect new features and prompt the users to accept them. If accepted, they will be enabled, resulting in the situation identical to 1). We propose to handle case 1) but not 2) and 3). If the user wants to 'doctor' their installed product manually (by copying files), we (Update) should not play police (users can also hack their Windows registries too, for example, and Windows allows them, even provides the tool for it - Regedit). Is the problem sufficiently addressed by handling the case 1) only?
We will address the problem as defined in 1) above. The fix is described in: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-update- home/doc/working/feature_extensions_2.html As a result of further discussions, we may tweak the spec by making the 'updateAllowed' flag recursive. What that would mean is that feature included using 'updateAllowed=false' and all of its subsequent children are protected from being masked by installing newer versions of them as root features (the original spec affects only the included child).
We have revised the initial intention. After further clarification, it became clear that the proposed attribute would only complicate matters and not resolve the main issue: the combination of the discovery URLs and the scope settings on the search page. The following set of step creates a problem: 1) A feature has a discovery site that points at the same URL as the update site 2) That feature is included in a larger product 3) The larger product wants to exclusively control updates to all the features in its hierarchy 4) Scope settings in the Available Updates search are set to include 'Sites to Visit' in scope The above sequence of steps may result in the new version of the included feature to show up as a result of a search, allowing users to update included feature from its own site (discovery site). We will close this loophole by preventing included features to add discovery sites to the 'Sites to Visit' folder. Only root features will be allowed to do so. If discovery sites are not contributed by the included features, they will not be placed on the list of sites to search for new updates. If the user creates a bookmark by typing the site URL explicitly, navigates to the feature and installs it that way, at that point it is considered an advanced user and will be allowed to proceed, assuming that he knows what he is doing.
Implemented - ready to test.
tested
