| Summary: | [ui] PreselectedIUInstallWizard(ProvisioningOperationWizard).getNextPage(IWizardPage) changes the profile | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Krzysztof Daniel <krzysztof.daniel> | ||||||
| Component: | p2 | Assignee: | Susan McCourt <susan> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | krzysztof.daniel, pascal, xavier_robert | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | 3.7 M3 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Krzysztof Daniel
It looks like ProvisioningUI is created only with profile _SELF_ or null. Could you please see if this is still a problem on 3.6? ProfilesView configures the InstallUIDropAdapter during startup when the tree is not configured yet. Created attachment 174845 [details]
Patch which fixes the issue
The issue happens in software checked out from HEAD.
The fix is not easy I think - my patch solves the problem, but it is a dirty hack.
Created attachment 174956 [details]
Better patch
Fixed in HEAD >20100901. The reason the fix seemed so awkward is that the InstallIUDropAdapter was ill-placed. That code attempts to figure out "which profile" is the one you want, yet its constructor required a ProvisioningUI which is presumed to already know the profile in question. Since the admin UI is the only place where the INstallIUDropAdapter makes sense, I moved the class and changed the constructor. (The class was internal so this move is safe). *** Bug 322138 has been marked as a duplicate of this bug. *** retargeting milestone. These changes were released to HEAD for M2, but never tagged for the M2 I-builds. Since we are already into the test pass, we will defer to M3. Verified on win7, Build id: I20101026-2000. |