Community
Participate
Working Groups
On the Target Management Update site (http://downloads.eclipse.org/dsdp/tm/updates) we have the following features and dependencies: TM SDK (includes TM Core, docs, sources and everything else) TM Core TM Ssh (requires TM Core) When I select "TM Ssh" an press "select required", I get the TM SDK selected. I'd expect to get only the TM Core selected since I dont't want sources and ISV docs. I've tried changing the site.xml files to change categories, sort order etc. but the problem persists -- Update Manager always selects SDK as dependency, although the Core would be sufficient. Wore general, if a feature X has dependencies Y,Z - and there are multiple possible features which are able to serve Y,Z - then the update manager should choose the one which serves Y,Z + and fewest other additional features.
The problem is still there in Eclipse 3.2.1 on the Callisto site: For instance, * Select "Enabling Features" > "Apache Commons Logging" --> Error is shown that log4j is missing * Click "Select Required" --> 6 (!) Features are selected, including full WST (!), EMF, XSD, GEF (!), VE Looking at this, the "Select Required" feature is pretty unusable, and user has to select the required features manually. I find this pretty annoying. Is a fix for this planned as part of a larger picture improving the Update Manager? Or what's going to happen with this bug? Do you want help for this?
Marking this as a bug now, because what it does to Enabling Features on the Callisto Discovery Site is certainly buggy.
As per the Europa conference call on Wed 18-Oct-2006, I wanted to bring this bug to the attention of cross-project.inbox and the Europa leaders... On http://wiki.eclipse.org/index.php/Europa_Simultaneous_Release it was mentioned that Europa should have both SDK and Runtime packages on its discovery site. I had mentioned that because of this bug, when selecting a runtime sub-feature, "Select Required" would not work at all if SDK packages were on the same site. Since Europa wants to go that route, I consider this issue as major. Anyone wants to look at it?
The minimum that UM must do, is when a feature is listed both explicitly and contained in a wrapper, the explicit dependency must be chosen. Folks, this is really a major issue for Europa. See also bug 175004 for a similar (but harder to solve) issue with bundle dependencies.
Dejan, this looks important for 3.3
As discussed in the Europa meeting at EclipseCon, I verified again that the "Select Required chooses SDK when Runtime is needed" issue is still there, and is still a major issue that I think should be fixed. I checked with eclipse-SDK-3.3M5eh-win32 on WinXP SP2. The issue is most easily reproducable from the TM update site (fast and small), but it is also visible on the Europa Discovery site. On the TM update site (http://download.eclipse.org/dsdp/tm/updates), select "RSE Runtime Only > RSE Local Services" and press "Select Required". --> RSE SDK is chosen instead of RSE Runtime. What's interesting is that the bug seems to be sensitive to very minor modifications. For instance, I could NOT reproduce the issue on the TM milestone site (http://download.eclipse.org/dsdp/tm/updates/milestones) but I could reproduce it on the TM nightly testUpdate site (http://download.eclipse.org/dsdp/tm/testUpdates) which is almost the same. On the Europa Discovery site, it is currently shown when selecting "Test and Performance > TPTP Profiling for Web Applications" and choosing "Select Required". --> The WTP SDK is selected instead of the WTP Runtime. Although right now the issue not very imminent for Europa (coarse granularity, so relatively few inter-project dependencies) I expect it to become more problematic soon, when more projects add their SDKs to the site (e.g. BIRT and CDT do not currently expose their SDKs on the Europa site; Dependency on those features will also be subject to getting SDK instead of runtime). See comment #4 for a minimal fix that I think must be implemented for Europa. In order to more clearly indicate that this is a major bug and not just an enhancement request, I changed the title (Previous title was: Select Required shold choose the minimal dependency if more options exist)
Dejan, do you have any comment regarding if this is feasible for 3.3 or not? It's an important issue for Europa.
Martin, does this mean users that use the "select required" option may be downloading lots of packages they don't actually need?
'Add required' function is an honest attempt, it was not meant to be correct in 100% of cases. The logic in this function is touchy. I will change it unless there is a patch by the community that proves to be solid. Update currently has one active committer (myself) so do not expect much for 3.3.
(In reply to comment #9) > The logic in this function is touchy. I will change it unless there is a patch Did you mean: "I will not change it" ?
Yes, sorry - it was a long day :-).
(In reply to comment #8) > Martin, does this mean users that use the "select required" option may be > downloading lots of packages they don't actually need? Yes. Exactly. They get lots of source features and isv docs. Perhaps for the concrete problem of SDK vs. Runtime, there is a rather simple fix that does not need to be very generic. The problem that UM "select required" needs to solve is: given bundle (or feature) X, who includes X? - It looks like right now, UM iterates over the features and as soon as a feature A is found which includes X (at any nesting level) it is taken. Given that typically, an SDK has its corresponding runtime feature as an "included feature" it would probably suffice if: - as soon as feature A is found with the current algorithm, UM checks the included features of A - and tries if the one which happens to hold the bundle in question is also listed in site.xml. So this would not really be a change of the algorithm, but rather some kind of post-processing to fine-tune the result once a feature candidate is found. I must admit, though, that this idea is just out of my observations and I have not looked at the code at all.
Martin, a question for you: If we find Runtime to contain the require feature as well as SDK AND it has less plug-ins to bring in, but SDK is newer (say, 1.0.1 over 1.0.0 for Runtime), should less plug-ins win or newer version?
Here is a concrete example from the update site listed above: org.eclipse.rse.sdk_1.0.1.v20061215a-oyabpho6o4KtC0S org.eclipse.rse.core_1.0.1.v20061129------AXrVWXgmmZ Update can pick either of these and satisfy the requirement. Core is smaller (less plug-ins) but SDK is newer (qualifier is lexicographically 'better'). Should we ingore the qualifier?
Ignore the previous - it does not matter. Here is the fix that I think will work: 1) If the two (or more) candidates to select have the same ID, pick the newer 2) If the two (or more) candidates to select have different IDs (different features), calculate total number of plug-ins they will bring and pick one with the least number. I tested the fix on the TM update site and it picked the runtime, not SDK. I also tested on the Europa site and everything seemed to work well.
Created attachment 63673 [details] The fix
Done.
(In reply to comment #13) > If we find Runtime to contain the require feature as well as SDK AND it has > less plug-ins to bring in, but SDK is newer (say, 1.0.1 over 1.0.0 for > Runtime), should less plug-ins win or newer version? If feature A includes B (and only B is required), I cannot see how A can be newer than B. It must include the exact same verbatim copy. I would consider an update site.xml that lists an SDK with a new runtime, and also separately lists an old runtime but not the new one, broken (can't be intentional IMHO). Thus I don't think the version makes any difference. Also, the examples you posted are old -- the algorithm for computing qualifiers has changed with 3.3M6. Therefore, the algorithm you described looks good to me. Of course multiple versions of the same feature need to be subject to version constraints as specified in the requiring features, but I guess if these are not met than it cannot be a candidate anyways.
