Community
Participate
Working Groups
We should indicate future deletion of the Platform authorization API, as outlined in: http://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process
Should also queue up the following API packages for deletion: org.eclipse.core.boot org.eclipse.core.runtime.model These packages are still available in the bundle org.eclipse.core.runtime.compatibility. They provide API that has been obsolete since Eclipse 2.1. Any API that was still valid was moved elsewhere, such as org.eclipse.core.runtime.
Here is the descriptive blurb I wrote for the authorization APIs in the migration guide: What is affected: Clients that call the following methods for storing and retrieving passwords in the platform keyring file: - Platform#addAuthorizationInfo - Platform#getAuthorizationInfo - Platform#flushAuthorizationInfo - Platform#addProtectionSpace - Platform#getProtectionSpace Description: These APIs were deprecated and superseded by new API in the org.eclipse.equinox.security.storage package in Eclipse 3.4. These APIs made use of a custom encryption algorithm that caused problems for organizations distributing and exporting Eclipse-based products. The system was also inherently flawed due to relying on a password supplied on the command line that users never set.
The summary of APIs I think we should mark for future deletion: Entire packages: org.eclipse.core.boot org.eclipse.core.runtime.model org.eclipse.ui.presentations Methods: - Platform#addAuthorizationInfo - Platform#getAuthorizationInfo - Platform#flushAuthorizationInfo - Platform#addProtectionSpace - Platform#getProtectionSpace These are all cases of API that are no longer functional in 4.2. Even if we never deleted them in the future, indicating they are marked for future deletion is the clearest possible signal that clients should not be referring to these APIs.
For reference, here is the porting guide entry we have in 4.2 describing the state of the presentation API: Description: The workbench presentation API allowed plug-ins to override certain aspects of the workbench appearance, such as the shape of view and editor tabs. This mechanism is fundamentally incompatible with the pluggable rendering and declarative styling systems in Eclipse 4.2, which offer applications complete control over all aspects of the workbench layout and style. Action required: Using the presentation API and extension point to customize the workbench appearance will no longer have any effect. Clients are encouraged to try out the provisional new API in Eclipse 4.2 for performing equivalent workbench customization. Complete rendering control can be achieved by supplying an org.eclipse.e4.ui.workbench.IPresentationEngine. Customization of fonts, spacing, and color can be achieved by supplying custom CSS style sheets via the org.eclipse.e4.ui.css.swt.theme extension point. For more details see the <a href="http://wiki.eclipse.org/Eclipse4/RCP/CSS">Eclipse 4 CSS Styling</a> wiki page.
This was agreed to at the March 7, 2012 PMC call: http://wiki.eclipse.org/Eclipse/PMC
I have documented in the javadoc that these APIs are queued for deletion: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=65f3b423aee84d38cc390178bf6f989a12148b0f http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=8e572d95f911993ec4176f139854fe62972b287b
And, the porting guide entries: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?h=R4_HEAD&id=cd9ca9f2cc221fb0eb272ff229637806fec39615
Shouldn't we also add this info to the 3.8 release for those moving from 3.x to 4.x?
Sure, I have cherry-picked the porting guide change to master: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=d0640648778fcc43dfbfa176d7f3d425f0e87bbb
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.runtime/+/169526
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.runtime/+/169614
