Community
Participate
Working Groups
New public API needs to be added to org.eclipse.update.core. When using the user-exclude update policy, a batch install operation was available. This included a batch verification of the configuration but it also included an individual verification which should have many of the same problems described below. However, once we moved to the managed-only policy we need a batch enable command since the enable operations are always separate from install operations. An example of a problem with the existing API with managed-only. Feature A includes plugin B; Feature A requires Feature C. Feature C requires plugin B. With the one step enablement and validation it is not possible to enable either feature A or feature C since enabling Feature A will require that Feature C is enabled and enabling Feature C will require that Feature A is enabled. Another problem with single enablement is the build to build upgrade of our base platform feature. featureA_1.0.0 requires featureC_1.0.0 (with perfect version match). Now to upgrade featureA and featureC to version 1.0.1 will fail. This is not possible with the existing API since an attempt to enable either of these features will fail. Validation will fail since we are only performing a validation on each individual enable operation. This problem has been fixed by adding a batch enable operation and a batch verification. The existing batch validation and install batch commands were used as starting points. A not quite accurate but simple validation algorithm is -start with array of existing features in configuration. -remove any features that will need to be disabled (old versions). -add any features that will be enabled. -verify that this results in a valid configuration. Additional details and a patch will be posted later.
Created attachment 55537 [details] Changes to javadoc API Wordpad document
Created attachment 55538 [details] API changes for enabling batch config This wordpad document contains the changes to the public API to support batch config.
Comment on attachment 55538 [details] API changes for enabling batch config Wrong file. Ignore this. This text is not correct.
Created attachment 55539 [details] Public API changes for batch config Additional public API needed for supporting batch config.
Created attachment 55613 [details] Proposed patch for update.core
Created attachment 55614 [details] proposed patch for update.ui
This patch includes changes included in patch for 163599, If necessary, I will regenerate this patch when 163599 is integrated into CVS. org.eclipse.update.core.model.FeatureModel.java - This includes a fix regressed by bug 140942, digest is not generated correctly org.eclipse.update.core.model.IncludedFeatureReferenceModel - bug 146869, optional feature fixed initializing optional extension but it didn't initialize remaining filter values. Fix put into FeatureModel preserves all feature model filter values coming from an update site. This set of fixes may need to be revisited one more time. org.eclipse.update.internal.operations.OptionalFeatureOperation is a new class. It contains methods that were in FeatureOperation. This was done so that the methods could be shared with EnableOperation. So FeatureOperation now extends OptionalFeatureOperation. ConfigOperation extends OptionalFeatureOperation. A side-effect of doing this is that previous references to IInstallFeatureOperation had to be changed to IFeatureOperation to be used with both InstallOperation and ConfigOperation. This was not a problem in the core. In the update.ui it resulted in needing 2 cast operations. The end result of the changes it that the flow should be the same except when using the new BatchConfigOperation with managed-only update policy. New batch validation routines were written. These consist of all of the validation that had been performed during install and enablement. It also includes a few fixes for logic errors found while testing.
I am providing a new patch. This one is based on 3.3 M5. Additional API was added for batch disable. An error was made in previous fix for regression caused by bug 140942. Previous fix put the wrong type on the featureIncludes list. The real problem was the lack of a constructor which I have added. This is a severe regression problem. I am also providing a new javadoc that contains the totally new API that has been added by this bug. I am also providing sample code snippets using the batch enable and batch disable.
Created attachment 58936 [details] Javadoc for new API
Created attachment 58937 [details] Patch file for update.core and update.ui
Created attachment 58940 [details] Fix for regression of bug 140942
Created attachment 58941 [details] code snippets for batch enable and batch disable
Can be released early in M7 (patch available) but that would violate API freeze in M6. Tagging for M7 tentatively (need API change escalation).
James, how much do you want this for 3.3? These are non-trivial changes that include API changes.
You are right. They are non-trivial. We want all of it. We are using in our 3.2 version but want in 3.3 so we don't have to patch there.
James, we may be able to get an API exception but the current code simply adds methods to IOperationsFactory. This is a breaking change because we didn't specify in Javadoc that IOperationsFactory is reference-only interface. You would need to create IOperationsFactory2 and add new methods there, and then make instanceof checks in code for the new interface before calling these methods.
Are you putting in patch for 163599? If so I will wait to regenerate after that is in. This also included a fix for a regression problem introduced by 140942. I think it would be best to move this to a new bug after I review my changes in more detail. 146069 is also mentioned in the text. I am not sure where it was in this patch. It may be that it also needs to be a separate bug but I will have to check it out. So I propose fixing the above 2 or 3 first, then I can recreate a patch for the API changes. This one will take a little longer since it would be good to make sure it still works in our build before dropping into eclipse.
Chris said he needs to rework the patch for 3.3 in bug 163599. In addition, I didn't check it for API changes (I think it changes APIs and will need PMC exception).
I have opened a new bug 182625 to cover patch for bug 140942 regression. All that is left is the new API stuff after Chris adds his bug 163599. In addition to IOperationFactory, the following interfaces were also enhanced. Do they have the same restrictions? IConfiguredSite IOperationValidator
James, every interface that is not clearly spelled out in Javadoc to be 'reference only - do not extend' cannot be changed. We must use the standard route for evolving interfaces: 1) Add the new methods in the new <name of the interface>2 type (e.g. IConfiguredSite2) that extends the original interface 2) Make ConfiguredSite implement IConfiguredSite2 3) Test the instance of the original interface using instanceof 4) If true, cast into the new interface and use the new methods
We have decided that it is too risky to refactor this for 3.3. Lets move this to 3.4.
Works for me.
Is this going to make it for 3.4?
Only if James give it another go.
What would be the deadline for submitting this?
James, check the 3.4 plan at eclipse.org. I assume we would want to make any API change before API freeze milestone, and any code change before feature-complete milestone (don't know the dates right now). In addition, sooner is better to have the opportunity to revert any code change that causes unexpected regressions.
The Eclipse Update component is no longer under development, and no longer exists in the Eclipse Platform 4.x stream. If this problem still occurs in Eclipse Platform 4.2 or later, please enter a new bug report against Equinox p2.
