gf doesn't work properly with maven project

[mrroman]

I've noticed that incorrect source path (with wrong number of asterisks) is inserted in front of path variable (in autoload/classpath.vim). It looks like this currently:

 83       let base = escape(root.sep.'src'.sep.'*'.sep.'*', ', ') . ','

and I think it should be

 83       let base = escape(root.sep.'src'.sep.'*'.sep.'**', ', ') . ','

to cover subfolder of packages.

[tpope]

That will recursively descend into all src directories. Surely that can't be right?

On Sat, Nov 30, 2013 at 4:12 PM, Konrad Mrożek notifications@github.comwrote:

I've noticed that incorrect source path (with wrong number of asterisks) is inserted in front of path variable (in autoload/classpath.vim). It looks like this currently:

83 let base = escape(root.sep.'src'.sep.''.sep.'', ', ') . ','

and I think it should be

83 let base = escape(root.sep.'src'.sep.''.sep.'*', ', ') . ','

to cover subfolder of packages.

— Reply to this email directly or view it on GitHubhttps://github.com/tpope/vim-classpath/issues/5 .

[mrroman]

I think it must be recursive, because vim won't find file. E.g. we have package com/abc/def in src/main/java. Vim will be looking only in src/main/java directory and the file will be in src/main/java/com/abc/def.

I don't know vim that much. Does your question have something in common with Java imports and resolving which file contains given class by what is declared in import statement?

[tpope]

Oh, the assumption is that you're gfing on an absolute name (like com.abc.def). A smarter gf could figure out your imports and qualify it that way. But I don't think just blindly scanning recursively is the answer.

[mrroman]

I agree that blindly scanning is not elegant, but it works for now :). Ok, I will work on the solution :).

[dhruvasagar]

I want to be able to find files, my previous solution was a mixture of set exrc and a project local .vimrc that sets up the path correctly (I use +='s) but classpath.vim completely overrides the path and so I loose that information. (Currently working on a java project with maven).

[tpope]

@dhruvasagar are you asking to put something in 'path' that isn't in the class path?

[dhruvasagar]

@tpope I would just like to be able to navigate the files more easily using gf, Ideally the classpath should also have the path of the source, but it isn't working for me.

[benknoble]

I'd like to re-open this discussion a bit: gf currently does work on qualified names, but :find is practically useless with only src/*/*—even typing the full filename out (which, IIUC, :find is to help me avoid) gives "file not found on 'path'" (E345). gf on a non-qualified name, such as a class in the current project, is also useless.

Granted, I have tags working well-enough for java, but I would like to also have gf/:find/:dsearch/:isearch working, and they (AFAIK) all rely on path being set well. (I know I need to set define and include/includeexpr to make the latter two work, but that's not really germane here.)

[tpope]

To start with, see my take on the purpose of 'path' in the Apathy README.

If your goal is to make gf on SomeClass in a file with import some.namespace.* find src/main/java/some/namespace/SomeClass.java, there are a few approaches you could take:

• On file load, parse out the import declarations, and add a path like src/*/*/some/namespace for each import wildcard. This is out of scope for classpath.vim, as my interest and ability stops at the JVM and this is a language specific solution.
• Remap gf to handle import resolution. This is my preferred technique: I use it in rails.vim and Fireplace among other places. Also out of scope for classpath.vim.
• Change 'path' to use ** globs, so that Vim finds any file named SomeClass.java buried at any level of the directory hierarchy. To which I say NO, absolutely not. Use a fuzzy finder if this is what you want.

[benknoble]

@tpope thanks for the comments; they've given me some ideas (parsing package declarations would actually probably be enough for my java use cases). I hadn't considered the limited scope of classpath, so that makes sense.