Community
Participate
Working Groups
In RSE IFileService, all methods are declared as "throws SystemMessageException". But in reality, the Services which compile without UI dependencies, have troubles creating a SystemMessageException properly, since the code which creates such exceptions by reading from XML requires UI dependencies -- for instance RemoteFileException. It should be clarified how Services are expected to report errors. Classes like RemoteFileException should be moved to non-UI part. Perhaps also RSEUIPlugin.getSystemMessage() and org.eclipse.rse.ui.ISystemMessages should be moved into non-UI plugins.
I believe several things need to be done for this: (1) The loading of message files from a bundle needs to be isolated from RSEUIPlugin and placed in core. This will be a new utility class. (2) The current (large) system message file and its constants should be split. One for UI (validation errors and the like) and one for the services (files, processes, shells, and general errors). The services one we will place in core along with its constants. Ideally we'd split this along service lines as well, but since all these services are defined in the core feature its a nice compromise. (3) Beef up the SystemMessageException API a tad to allow the construction of reasonable messages if a contributor does not which to use the message file mechanism. (4) Make sure that RSEUPPlugin takes advantage of the new support. I'm thinking we'll want to search multiple message files now as follows - the nationalized message file for UI, the English message file for UI, the nationalized message file for Core, the English message file for Core. This will allow plugins dependent on the UI to just go to the UI for their messages and makes compatibility a bit nicer. Comments?
From the ssh service standpoint (and probably others who want to extend RSE), I'm most interested in (3) and I'd hope this can be implemented first. I'm not sure how many messages are needed by other non-UI services. Perhaps it would make sense to migrate all on-UI services to using the standard Eclipse mechanisms for localized messages? Then, (1,2,4) would not be necessary any more. The Eclipse Platform supports externalized strings, localization and pattern substitution through the NLS class and java MessageFormat, and this appears the standard way of handling localizations in most Eclipse projects. What are the unique advantages of using SystemMessages.xml compared to what the Platform already offers?
The SystemMessage mechanism supports several things that are not supported by the Eclipse base and that are required by by users of target systems supported by IBM. Message IDs, message details, and message typing are among these. I cannot support migrating the core of RSE to a different mechanism at this point in time - it has a significant implementation cost and buys us nothing except simplicity of translation. However, the translations for eclipse components are typically done by IBM and donated back and the IBM translation centers are familiar with this format.
For part (3) I moved the RemoteFileException hierarchy to org.eclipse.rse.services.files package. Here it can be exploited directly by the services. Hardcoded the any SystemMessage creation for now. This will be changed when the message file DTD is moved and message file utilities are created. Fixed javadoc where appropriate.
Lowering priority to P2 to finish the rest of the work.
See also bug 154207 for forwarding exceptions properly.
Dave McKnight's solution to 154207 relieves some of the pressure to move the message definitions immediately so I'm downgrading this to 3. I will be moving the DTD.
It turns out the DTD does not need to be moved. The stream containing it is established in SystemUIMessageFile which is in the correct plugin.
[target cleanup] 1.0 M5 was the original target milestone for this bug
