Community
Participate
Working Groups
URI cannot be resolved to a type org.eclipse.ui.workbench/Eclipse UI/org/eclipse/ui IURIEditorInput.java line 39 1163611136718 748662 This is API that was added in 3.3. Since URI is not part of J2ME Foundation 1.0, can we do without this API?
I have no idea... this is the first I've heard of this class. Tod, you checked it in... can you give some history?
No we can't - it was aded for EFS support. We could move it to IDE though. Adding Dani and Michael to check if we need this at the workbench level.
What I was asking for (see bug 111887) was a file editor input for file stores. When we discussed this we thought URI would be a nice generalization. We might back off from IURIEditorInput if it hurts too much. Putting it into IDE is wrong from an architectural standpoint. Instead we could introduce IFileStoreEditorInput at the IDE level which has a getFileStore() method and wait until we get concrete request for IURIEditorInput.
The org.eclipse.core.filesystem plugin requires a 1.4 JRE because it uses URI. I see no choice but to put IFileStoreEditorInput into IDE... Dani, in which plugins do you need IFileStoreEditorInput?
We have the same problem with IEditorLauncher - it can only open an editor on IPath. If we wanted to support providing editor launcher for URI it would logically go in workbench. It seems that some parts of the editor framework make the bad assumption that editor inputs are files in the local file system.
I'm a little confused by John's comments. Can't we just do what Dani proposed in comment #3? This is what I refer to: > Instead we could introduce > IFileStoreEditorInput at the IDE level which has a getFileStore() method and > wait until we get concrete request for IURIEditorInput.
>It seems that some parts of the editor framework >make the bad assumption that editor inputs are files in the local file system. Well, so far there are neither dialogs nor editor inputs (with the exception of this ongoing work) that can handle arbitrary EFS. Just Platform Text's internal implementation to support the local FS. Currently we are in the middle of actually trying to add better support to open editors via the new the (I)FileStoreEditorInput. I guess what John wanted to express is that there are plug-ins that - once the support is there - would like to open an editor using IFileStore (or URI) without depending on the IDE plug-ins. Here are some related issues: - bug 116414 - bug 49495
(In reply to comment #7) > ... I guess what John wanted to > express is that there are plug-ins that - once the support is there - would > like to open an editor using IFileStore (or URI) without depending on the IDE > plug-ins. This sounds like a reasonable request, but would require creating a new plug-in. We cannot use URI in org.eclipse.ui.workbench, so IURIEditorInput has to be removed, or moved into another plug-in. I would like to find a solution for this as soon as possible since it is blocking bug 121434.
I said the wrong thing in comment #4 - I meant to suggest simply moving IURIEditorInput into IDE. To me IFileStoreEditorInput and IURIEditorInput are almost equivalent, except IFileStoreEditorInput ties the client to an eclipse-specific abstract (IFileStore), rather than a general Java class library abstraction (URI), so the latter seems preferable to me.
John so it sounds like the best course of action is to remove IFileStoreEditor and replace it with IURIEditorInput in the IDE. Do you agree?
There is currently no IFileStoreEditorInput - this was just suggested by Dani in comment #3. Currently we have a FileStoreEditorInput class in IDE plugin, and IURIEditorInput interface in workbench plugin. We need to move IURIEditorInput to the IDE plugin, and fix up any existing references accordingly.
Lets move it to IDE as suggested.
I have deprecated IURIEditorInput in the workbench and moved it to org.eclipse.ui.ide.IURIEditorInput. I will remove the workbench version when I get the go ahead from Dani. Fixed for build >20070214
This should get a PMC +1. Since the API is being removed from one plugin and added to another, it's an API change. I agree it's a necessary change because the current API requires a 1.4 EE.
>This should get a PMC +1. You need to send your request to 'eclipse-pmc@eclipse.org' and if no PMC votes -1 in 24 hours it means GO. This was agreed on in last weeks arch call to speed up the process.
I spoke to Tod about this one yesterday. I wanted him to verify that none of the intended consumers of this were going to now be constrained to have a dependency on the IDE that they otherwise might have avoided. I.e. Could this be a problem for RCP apps?
Michael Valenta and I were talking and his feeling (which I agree with) is that we should leave IURIEditorInput in the org.eclipse.ui package but move it to the extensions in ide. That way if at any time we either step up to 1.4 or add a 1.4 extensions plug-in the workbench ide is not in the name and we have no API breakages to worry about. I am going to reopen this pending feedback on this and approval from the PMC when we are happy.
Just make sure to coordinate the change as otherwise you will break the build: Platform Text now uses FileStoreEditorInput at several places and expect it to inherit from org.eclipse.ui.ide.IURIEditorInput.
Michael's suggestion makes sense to me. It's quite possible workbench will be able to move to at least Foundation 1.1 in the future, which contains URI. At that point we would be able to move the interface down to workbench from IDE without breaking anyone.
Dani I am going to move IURIEditorInput after the integration build submission this week - I will synch with you to find a good time to do this.
Let's do it today as soon as you're in, so that we have it in the next I-build.
IURIEditorInput moved to org.eclipse.ui in the ide plug-in so it now has the same signature but is in a different plug-in. I will remove all of the deprecated classes before the next I build.
Adding Darin as this may affect ant
Adding Darin (S) as there are references to FileStoreEditorInput in Ant, which implements IURIEditorInput.
Darin, I checked your code and verified that it is not affected by the latest change.
ide version of IURIEditorInput deleted for build >20070228
Verified in I20070320-0010
