Community
Participate
Working Groups
In 3.5, we introduce a new extension point, org.eclipse.ui.installationPages, and API for the pages that are contributed in InstallationPage. These pages appear in the "Installation Details" dialog that is launched from Help>About. The interface used for a page to communicate with its container is defined in IInstallationPageContainer. This interface was never marked with any API tooling tags. In bug #275298 comment #5, it was suggested this interface be marked as @noimplement. Since the intention of the extension point is that clients implement and contribute InstallationPage, and not that clients provide alternate implementations of the containing dialog, this interface should be marked @noimplement.
Created attachment 138031 [details] patch patch to add @noimplement
Adding Boris and John for review. Will send a note to eclipse-pmc. There are already bugs open for additional services to be provided by IInstallationPageContainer. See bug 265207 bug 264084 bug 266186 It's not clear yet that these bugs will cause API additions to the interface itself, but since we have already targeted improvements in this area, it seems prudent to allow the API to evolve rather than introduce IInstallationPageContainer2, etc....
+1, this is was clearly just an oversight. The main purpose of splitting InstallationPage from IInstallationPageContainer was to allow the container to evolve without breaking existing page implementations. If we don't add this tag we will certainly need an IInstallationPageContainer2, ...3, etc. Although this is a breaking contract change, I think it is not high risk because it doesn't immediately break binary compatibility so clients will have time to react. If any client exists today that implements the container (unlikely), they will only be broken when we add methods to the container in a future release. It's better to do the right thing now than to be forced into the API bloat of adding extension interfaces in the future.
Just to clarify. (I think John got the point, but used the wrong class name). IInstallationPageContainer was not split from InstallationPage (which is also API). It was split from org.eclipse.ui.internal.about.InstallationDialog, which is internal. The idea here is that pages need to communicate with their container to do things like add buttons, but we don't want to expose the underlying implementation of the containing dialog.
Yes, thanks for clarifying. By "split" I just meant "kept separate from". I.e., the API was designed to have the two pieces in separate classes (the part for the client to implement, and the interface from the client back to its context/container).
Agree that it makes sense to do this now.
released to HEAD for 20090603-2000.
verified through source inspection, WinXP, I20090603-2000.
