Community
Participate
Working Groups
I need class 'HyadesEditorPart' to be non-internal. An instance of this class is returned by Eclipse UI.
And org.eclipse.hyades.test.ui.internal.editor.TestSuiteEditorPart too.
And these: import org.eclipse.hyades.test.ui.internal.editor.BaseEditorPart; import org.eclipse.hyades.test.ui.internal.editor.ExecutionEditorPart
Reassign to Jerome for tptp 4.2. This defect also includes the Test Log viewer that Bianca will work on.
HyadesEditorPart, TestSuiteEditorPart and BaseEditorPart are all part of the TPTP Test Editor framework implementation which is on its way to deprecation because there has been repeatedly requested to move to eclipse forms based editors but hasn't been staffed. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=78903. Any internal classes are NOT intended to be used externally to start with. This is a eclipse-wide packaging convension. Underlying tools should only use them on their own risk. To public these classes we have no intension to maintain and are deprecating soon is the last thing we should do. However, before the new eclipse forms based framework is available as an alternative, if there's any flaws in the public APIs that preventing users from using the framework, we should fix it. A good example is interface IHyadesEditorPart doesn't expose the access to IEditorExtension (i.e. there's no method in IHyadesEditorPart like: IEditorExtension getEditorExtension()) which is only implemented as a final method in internal HyadesEditorPart. This method is a must to gain access to part of the framework at API level. I suggest we provide IHyadesEditorPartExtended which extends IHyadesEditorPart that contains method IEditorExtension getEditorExtension(). Then make HyadesEditorPart (or one of its super class) to implement IHyadesEditorPartExtended instead of IHyadesEditorPart. As for ExecutionEditorPart, it is already not used by the new Test log viewer in TPTP 4.1 which is the first eclipse forms based editor re-implemented not using the old Hyades editor framework. If you need to extend the new Test log viewer and there's no extensibility available, please check the extensibility enhancements targeting 4.2 or later (bug 103555, bug 89337, bug 109182). If still not what you need, please feel free to talk to me directly.
My understnding is that these classes are used by clients mostly because you need to something along the lines with the following: if( activePart instanceof TestSuiteEditorPart ) // do something else( activePart instanceof ExecutionEditorPart ) // do something else. See Protocol Data View viewer.
I am reassinging this defect to Bianca to ensure that we don't inadvertently make these APIs public. We can discuss the concerns with using the internal APIs, but we should not make these public since it is our plan to remove them when we migrate to eclipse forms. The fact that consuming products need to use internal interfaces should bolster the argument to staff the migration to eclipse forms, or revisit that direction as a whole.
With all due respect, these particular classes have nothing to do with Forms UI. They are used to implement an *editor*, NOT *widgets*. It is classes like EditorForm and Editor section that are going to be replaced by Forms UI. But, regardless of what kind of widget factory is used, the classes that implement editors should stay and be public.
Not only widget factory will be replaced by org.eclipse.ui.forms.widgets.FormToolkit and forms becomes org.eclipse.ui.forms.editor.IFormPage, the editors themselves should be org.eclipse.ui.forms.editor.FormEditor as well which will inevitablly affect the implementations of the editor classes.
As long as I can *legitimately* query editor types, access their methods, and editor extinsions, this is fine. Just keep in mind, that sometimes it is not the EditorExtension that I am interested in, but the _editor_ itself (i.e. its type).
As discussed and agreed on TPTP Test Project weekly meeting on 1/30/2006, these editor base classes are part of the Test editor framework that will be changed when all test editors migrate to eclipse forms editors (see bug 74949) However, eclipse forms migration is not expected to happen in 4.2 because of the size of the work and its impact on consuming products. Thus these internal classes will be handled as part of the eclipse forms migration work and will not become public before that happens. However since consuming tools have dependency on these internal classes, they should be made sure not to have API breaking changes from release to release while they are internal.
No action to take for this defect other than keep the internal API as it is until alternative API is available from feature 74949. *** This bug has been marked as a duplicate of 74949 ***
ACTION: Please update the target to the release AND iteration that this defect was returned/fixed.
ACTION: Please verify/close this defect.
Closing by default since not closed by the originator in the 7+ months since being resolved. Please reopen if the issue is still present in the latest TPTP release or the resolution is not correct.
This leaves me no alternative but to continue using the internal classes (see usecases in comment #5 below) which violates IBM guidelines.
