|
Re: Open editor in the presence or nested projects , API question [message #1031043 is a reply to message #1030909] |
Mon, 01 April 2013 04:58 |
Ed Merks Messages: 33107 Registered: July 2009 |
Senior Member |
|
|
Robin,
Comments below.
On 01/04/2013 2:01 AM, Robin Rosenberg wrote:
> EGit is using IDE.openEditor
There are almost a dozen of such methods. Which one?
> to open an editor from the Git History (CommitFileDiffViewer.java) in
> EGit, but I cannot see an API
> that makes sure it opens the resource in the most nested projects,
> usually the Java Project that contains he resource.
I imagine this one opens exactly the IFile you specify:
org.eclipse.ui.ide.IDE.openEditor(IWorkbenchPage, IFile, boolean)
So I guess that's not the one you're using.
> I just assume that is the right thing to
> do.
It's not so specific what you're doing.
>
> The layout of the projects are:
>
> <workspace>/jgit/.project (named jgit) (top project of type General)
> <workspace>/jgit/org.eclipse.jgit/.project (top project, of type Java)
>
> How do I open resource (say
> jgit/org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java as
> src/org/eclipse/jgit/api/AddCommand.java withing P/org.eclipse.jgit
> rather than org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java
> within P/jgit ?
If you know the IFile you want, you should be able to use that
approach. I suppose in general you can't assume there exists a
corresponding IFile. This method could be used to locate all such
corresponding IFiles and from that you could use a "most deeply nested"
criterion to choose among them.
org.eclipse.core.internal.resources.WorkspaceRoot.findFilesForLocationURI(URI)
Of course you could fail to find one, in which case you'd need to use
some other form of editor input, e.g., one for the direct file system.
Does EGit integrate with EFS to support its own URI scheme so that it
can avoid bugs such as this one?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=354801
>
> For most resource types there is no problem, but some resources, such
> as Java files, must be interpreted in the
> context of a specific project for all functionality to be available.
Another problem is one like the bug above, where the resource contains
references other resources via relative URIs, and needs to resolve them
in the same historical state and relative to the logical project
structure in the workspace (not the physical structure in the git repo).
>
> See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=404629
>
> -- robin
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Open editor in the presence or nested projects , API question [message #1031442 is a reply to message #1031043] |
Mon, 01 April 2013 19:11 |
Robin Rosenberg Messages: 332 Registered: July 2009 |
Senior Member |
|
|
Ed Merks skrev 2013-04-01 06.58:
> Robin,
>
> Comments below.
>
> On 01/04/2013 2:01 AM, Robin Rosenberg wrote:
>> EGit is using IDE.openEditor
> There are almost a dozen of such methods. Which one?
>> to open an editor from the Git History (CommitFileDiffViewer.java) in EGit, but I cannot see an API
>> that makes sure it opens the resource in the most nested projects, usually the Java Project that contains he resource.
> I imagine this one opens exactly the IFile you specify:
>
> org.eclipse.ui.ide.IDE.openEditor(IWorkbenchPage, IFile, boolean)
>
> So I guess that's not the one you're using.
>> I just assume that is the right thing to
>> do.
> It's not so specific what you're doing.
>>
>> The layout of the projects are:
>>
>> <workspace>/jgit/.project (named jgit) (top project of type General)
>> <workspace>/jgit/org.eclipse.jgit/.project (top project, of type Java)
>>
>> How do I open resource (say jgit/org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java as src/org/eclipse/jgit/api/AddCommand.java withing P/org.eclipse.jgit rather
>> than org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java within P/jgit ?
> If you know the IFile you want, you should be able to use that approach. I suppose in general you can't assume there exists a corresponding IFile. This method could be
> used to locate all such corresponding IFiles and from that you could use a "most deeply nested" criterion to choose among them.
>
> org.eclipse.core.internal.resources.WorkspaceRoot.findFilesForLocationURI(URI)
Ok. I think that solves the problem. Thanks. I forgot that an IFile is a resource name, not a filename.
-- robin
|
|
|
Powered by
FUDForum. Page generated in 0.02306 seconds