Bugzilla – Full Text Bug Listing
| Summary: | [api] Require an extension point to specify file transfer mode (binary/ascii) for a specific filetype | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] Target Management | Reporter: | Ankit Pasricha <ankitp> | ||||||
| Component: | RSE | Assignee: | David McKnight <dmcknigh> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Martin Oberhuber <mober.at+eclipse> | ||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | ddykstal.eclipse | ||||||
| Version: | 2.0.1 | Keywords: | api | ||||||
| Target Milestone: | 3.0 M4 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 203114, 207308 | ||||||||
| Attachments: |
|
||||||||
|
Description
Ankit Pasricha
Dave what do you think -- should we add an extension point that's evaluated by the SystemFileTransferModeRegistry? Such that when a user-configured association of text vs. binary is not made, it can get the fallback from the extension point? The extension point might also be used to "lock" certain associations similar to what the editor associations preference page provides. We had this extension point in the IBM RSE version - I'm not sure why we never put it in open RSE, since the extension point was pretty simple. I've been thinking about changing the way we do these associations due to a couple other bugs: bug 203114 -File transfer mode Preference Page has invisible defaults and bad UI bug 207308 -Removing a file type should not delete the platform's file association to editors Right now we're picking up our file types from the editor registry. In the team preferences, there's a separate set of file type associations used for tools like cvs. It would be nice if these things could be consolidated although that could take a while. Otherwise, we may end up duplicating the work that team did. Created attachment 82788 [details]
patch to add remoteFileTypes extension point
Here's a patch with changes needed to put in the basic remoteFileTypes extension point. This is basically what we have in the older IBM RSE. Unfortunately, we never displayed these types in the preference page but we could handle that in one of the other defects.
Created attachment 82803 [details]
patch with changes to preferences
This patch is basically some hacks to see how feasible it would be to use the extension point along with whatever was saved previously to determine the file type modes. In this case we show our associations in the preference page but without using the editor registry. To do this right, I'd have to clean this up a bit but I'm putting this out there to get opinions.
Any thoughts?
I guess we'll want to think about migration of old RSE 2.0 workspaces when moving to the new scheme. Suppose that when no RSE 3.0 user prefs exist, but RSE 2.0 user prefs do exist, these should be migrated. (In reply to comment #5) > I guess we'll want to think about migration of old RSE 2.0 workspaces when > moving to the new scheme. Suppose that when no RSE 3.0 user prefs exist, but > RSE 2.0 user prefs do exist, these should be migrated. Actually, I don't think this is a problem, because, with the new scheme, we're already picking up the mappings the user had and saved with the old scheme. I've committed the extension point and code to cvs. In subsystems.files.core/plugin.xml, I've provided some defaults to use. (In reply to comment #7) Please also add your new extension point to org.eclipse.rse.doc.isv reference/extension-points/index.html topics_Reference.xml > In subsystems.files.core/plugin.xml, I've provided some defaults to use. Given the ambiguity / precedence problem, how would an ISV change these defaults? Could he use the plugin_customization.ini method? If yes, then please try and document it in the *.exsd file. (In reply to comment #8) > (In reply to comment #7) > Please also add your new extension point to org.eclipse.rse.doc.isv > reference/extension-points/index.html > topics_Reference.xml I've now added that to the doc.isv plugin. > > In subsystems.files.core/plugin.xml, I've provided some defaults to use. > Given the ambiguity / precedence problem, how would an ISV change these > defaults? Could he use the plugin_customization.ini method? If yes, then please > try and document it in the *.exsd file. I'm not sure how we should deal with the extension point conflicts yet. Currently, the first contribution wins. I guess adding a priority field is one way to deal with it. I've added a priorty field to the extension point. The lower the value of the priority, the higher the precedence. |