1. Right-click on folder in project
2. Select New->File menu item
3. Select "Advanced >>" button
4. Check "Link to file in the file system" checkbox
5. Select "Variables..." button
6. Select PROJECT_LOC variable
7. Continue entering path from the project root to the resource to
link in
Now, Eclipse can handle this file fine. When I choose "Open Call
Hierarchy" from the Eclipse context menu, and the selected function
traces through the linked file, Eclipse traces the call tree through
the file.
But, when I try the same operation in Vim, I get:
java.lang.RuntimeException:
org.apache.commons.vfs.FileSystemException: Could not find file with
URI "PROJECT_LOC/path/to/file.c" because it is a relative path, and no
base URI was provided.^M
while executing command (port: 9091): -command c_callhierarchy -p
"MYPROJECT" -f "path/to/file.c" -o 2232 -l 19 -e latin1
:CSearch at least finds things in this file just fine; I'm not sure
about other commands.
I tried editing the link path to the file in Eclipse, to use $
{PROJECT_LOC} instead of just PROJECT_LOC, but I get the same error
message (except PROJECT_LOC is replaced with a literal ${PROJECT_LOC}
in the massage text).
Probably I should file a bug report, but is there an easy workaround
for this problem? Or maybe, a way to define a linked file in Eclipse
which provides the required information (like a "base URI" maybe) for
this operation to succeed?
On Feb 8, 2:27 pm, Ben Fritz <fritzophre...@gmail.com> wrote:
> But, when I try the same operation in Vim, I get:
> java.lang.RuntimeException:
> org.apache.commons.vfs.FileSystemException: Could not find file with
> URI "PROJECT_LOC/path/to/file.c" because it is a relative path, and no
> base URI was provided.^M
> while executing command (port: 9091): -command c_callhierarchy -p
> "MYPROJECT" -f "path/to/file.c" -o 2232 -l 19 -e latin1
I should mention, "the same operation in Vim" is using
the :CCallHierarchy command, and I'm running:
eclim 1.7.2 with the following patches to the Vim scripts:
* move version guard to top of plugin/eclim.vim to exit early for old
Vim versions
* save/unset/restore 'autochdir' option during ProjectGrep operation
* patch from this list, to autoload/eclim/util.vim, which fixes byte
offsets when 'encoding' differs from 'fileencoding'
> 1. Right-click on folder in project > 2. Select New->File menu item > 3. Select "Advanced >>" button > 4. Check "Link to file in the file system" checkbox > 5. Select "Variables..." button > 6. Select PROJECT_LOC variable > 7. Continue entering path from the project root to the resource to > link in
> Now, Eclipse can handle this file fine. When I choose "Open Call > Hierarchy" from the Eclipse context menu, and the selected function > traces through the linked file, Eclipse traces the call tree through > the file.
> But, when I try the same operation in Vim, I get:
> java.lang.RuntimeException: > org.apache.commons.vfs.FileSystemException: Could not find file with > URI "PROJECT_LOC/path/to/file.c" because it is a relative path, and no > base URI was provided.^M > while executing command (port: 9091): -command c_callhierarchy -p > "MYPROJECT" -f "path/to/file.c" -o 2232 -l 19 -e latin1
> :CSearch at least finds things in this file just fine; I'm not sure > about other commands.
> I tried editing the link path to the file in Eclipse, to use $ > {PROJECT_LOC} instead of just PROJECT_LOC, but I get the same error > message (except PROJECT_LOC is replaced with a literal ${PROJECT_LOC} > in the massage text).
> Probably I should file a bug report, but is there an easy workaround > for this problem? Or maybe, a way to define a linked file in Eclipse > which provides the required information (like a "base URI" maybe) for > this operation to succeed?
I just checked in a fix[1] for this which fixes the issue with :CCallHierarchy and potentially several other commands.
>> java.lang.RuntimeException: >> org.apache.commons.vfs.FileSystemException: Could not find file with >> URI "PROJECT_LOC/path/to/file.c" because it is a relative path, and no >> base URI was provided.^M >> while executing command (port: 9091): -command c_callhierarchy -p >> "MYPROJECT" -f "path/to/file.c" -o 2232 -l 19 -e latin1
>> :CSearch at least finds things in this file just fine; I'm not sure >> about other commands.
>> I tried editing the link path to the file in Eclipse, to use $ >> {PROJECT_LOC} instead of just PROJECT_LOC, but I get the same error >> message (except PROJECT_LOC is replaced with a literal ${PROJECT_LOC} >> in the massage text).
>> Probably I should file a bug report, but is there an easy workaround >> for this problem? Or maybe, a way to define a linked file in Eclipse >> which provides the required information (like a "base URI" maybe) for >> this operation to succeed?
> I just checked in a fix[1] for this which fixes the issue with > :CCallHierarchy and potentially several other commands.
Thanks, I suppose I won't bother with the bug report in the issue tracker then. A fix is certainly better than a workaround :-). Now I'll just need to learn how to install from source, unless 1.7.3 is coming out soon...
> On Thu, Feb 9, 2012 at 12:06 AM, Eric Van Dewoestine <ervan...@gmail.com> wrote: > > On 2012-02-08 12:27:14, Ben Fritz wrote:
> >> java.lang.RuntimeException: > >> org.apache.commons.vfs.FileSystemException: Could not find file with > >> URI "PROJECT_LOC/path/to/file.c" because it is a relative path, and no > >> base URI was provided.^M > >> while executing command (port: 9091): -command c_callhierarchy -p > >> "MYPROJECT" -f "path/to/file.c" -o 2232 -l 19 -e latin1
> >> :CSearch at least finds things in this file just fine; I'm not sure > >> about other commands.
> >> I tried editing the link path to the file in Eclipse, to use $ > >> {PROJECT_LOC} instead of just PROJECT_LOC, but I get the same error > >> message (except PROJECT_LOC is replaced with a literal ${PROJECT_LOC} > >> in the massage text).
> >> Probably I should file a bug report, but is there an easy workaround > >> for this problem? Or maybe, a way to define a linked file in Eclipse > >> which provides the required information (like a "base URI" maybe) for > >> this operation to succeed?
> > I just checked in a fix[1] for this which fixes the issue with > > :CCallHierarchy and potentially several other commands.
> Thanks, I suppose I won't bother with the bug report in the issue > tracker then. A fix is certainly better than a workaround :-). Now > I'll just need to learn how to install from source, unless 1.7.3 is > coming out soon...
It should be out soon. I just have a few more small fixes and some testing to do, but I just started a new job so I make no promises as to when I'll have it done.
> Yeah it should be painless to build eclim. With the latest master > branch you can even ignore the -Dplugins argument which is no longer > needed.
So how do I build only the tools I'm interested in (CDT) with the latest master branch? I certainly don't have all the required tools installed for all the Eclim features! Currently the build guide says:
"...ant...will build all the eclim plugins, requiring you to have all the related dependencies already installed in your eclipse distribution. However, if you only want a subset of the eclim plugins to be built, you can specify so using the ‘plugins’ system property"
> On Thu, Feb 9, 2012 at 11:55 AM, Eric Van Dewoestine <ervan...@gmail.com> wrote: > > On 2012-02-09 10:58:44, Benjamin Fritz wrote: > >> (http://eclim.org/guides/development.html#development-build makes it > >> look pretty easy, although I'll need to install ant and maybe some > >> other things first)
> > Yeah it should be painless to build eclim. With the latest master > > branch you can even ignore the -Dplugins argument which is no longer > > needed.
> So how do I build only the tools I'm interested in (CDT) with the > latest master branch? I certainly don't have all the required tools > installed for all the Eclim features! Currently the build guide says:
> "...ant...will build all the eclim plugins, requiring you to have all > the related dependencies already installed in your eclipse > distribution. However, if you only want a subset of the eclim plugins > to be built, you can specify so using the ‘plugins’ system property"
The docs on eclim.org are out of date as far as the git master is concerned. Now when building the code, the build script will check what features your eclipse has and build the appropriate eclim plugins accordingly.
