Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 336015

Summary:

[ui] ProvisioningOperationWizard will not use ProfileChangeOperation

Product:

[Eclipse Project] Equinox

Reporter:

Matthew Piggott <matthew>

Component:

Assignee:

Matthew Piggott <matthew>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

irbull, pascal, susan

Version:

3.7

Target Milestone:

3.7 RC1

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
TestCase	pascal: review+
Use ProvisioningContext from ProfileChangeOperation	pascal: review+

Description Matthew Piggott

2011-02-01 15:38:37 EST

Subclasses of ProvisioningOperationWizard will never use the ProfileChangeOperation it is initialized with because it will always recompute the plan when getNextPage is called.  The method provisioningContextChanged is always true because provisioningContext is not initialized and getProvisioningContext() returns a new instance of ProvisioningContext.

InstallWizard overrides getProvisioningContext but returns instances of ProvisioningContext

Comment 1 Matthew Piggott

2011-02-01 16:13:49 EST

Created attachment 188089 [details]
TestCase

This test case is fairly simple, I've created a useless subclass of InstallOperation and the operation on the second page of the wizard is no longer of that type.

In my usecase I have a subclass of an InstallOperation which sets the restart policy of the provisioning job.  However, I believe this would also be an issue for users who expect their InstallOperation to use a specified ProvisioningContext (ie with some set of repos).

Comment 2 Susan McCourt

2011-02-02 12:31:15 EST

This surprises me because I know we have update cases where we compute the updates and preserve them in the wizard, but this is probably on the first page.  Can we not just initialize the provisioning context to the one from the operation as a fix?

Comment 3 Susan McCourt

2011-02-02 12:35:29 EST

Also, I don't think you should assume that the operation would never change in the wizard (ie, if the user changes selections, or decides to contact all sites, or something that might change the resolution).  Since these classes are internal we've not really been formal about the lifecycle, we've just done what works for the SDK.  So if you need that to happen, then that is a new feature.

But I agree that if nothing has changed, we shouldn't have to resolve again.

Comment 4 Pascal Rapicault

2011-02-02 21:41:40 EST

Matt could you please work on a patch?

Comment 5 Matthew Piggott

2011-02-03 13:20:48 EST

Created attachment 188261 [details]
Use ProvisioningContext from ProfileChangeOperation

I believe this should fix the issue for recomputing the plan.

There are a few small changes:
- ProvisioningOperationWizard constructor sets the ProvisioningContext to that of the operation (if not null)
- ProvisioningOperationWizard getProvisioningContext returns the context of the operation, or creates a new one
- UpdateWizard getProfileChangeOperation no longer sets the ProvisioningContext (this was unnecessary as recomputePlan also sets it)

Comment 6 Ian Bull

2011-04-21 13:51:02 EDT

Matt, are you still working on this?

Comment 7 Pascal Rapicault

2011-05-10 10:27:55 EDT

I've released the patch.