Maven created classpath is not used for file search
Kannan
folder. By default, this file contains location of all the source code
and library. How does this integrate with classpath files generated by
maven plugin? The classpath files generated by maven plugin are not
being used to search for files, code completion. Instead the root
classpath is being used. I am not able to figure out the right way to
generate classpath only from pom files.
Here is my code structure:
/home/krajah/TestProject --> Project root
/home/krajah/TestProject/main --> this folder has a root pom.xml
/home/krajah/TestProject/main/module1 --> this folder has a pom.xml
/home/krajah/TestProject/main/module2 --> this folder has a pom.xml
Some general questions:
- File search uses classpath file. Should we edit the classpath file
to limit the search to certain folders or is there any filter option?
- Is there a way I can specify the name of a project?
- I use VIM code completion. The preview pane pops up if there is more
than one match. If I close it can I bring it back on-demand? Eclipse
displays a window showing the Javadoc, it will be good to have this
feature as part of VIM preview pane.
Eric Van Dewoestine
> folder. By default, this file contains location of all the source code
> and library. How does this integrate with classpath files generated by
> maven plugin? The classpath files generated by maven plugin are not
> being used to search for files, code completion. Instead the root
> classpath is being used. I am not able to figure out the right way to
> generate classpath only from pom files.
>
> Here is my code structure:
> /home/krajah/TestProject --> Project root
> /home/krajah/TestProject/main --> this folder has a root pom.xml
> /home/krajah/TestProject/main/module1 --> this folder has a pom.xml
> /home/krajah/TestProject/main/module2 --> this folder has a pom.xml
The eclipse jdt expects the .classpath file to be at the root of the
project. I don't think the jdt has a means to configure a different
location for this file.
Given your layout, I would suggest creating 3 projects: main, module1,
and module2. I'm guessing that module1 and module2 both depend on
main, so when creating those projects, you can specify their
dependency on main, which will give them access to main's classpath
when validating, completing, etc. If module2 depends on module1 or
vice versa, then you can specify that dependency as well.
Ex.
:ProjectCreate /home/krajah/TestProject/main -n java
:ProjectCreate /home/krajah/TestProject/module1 -n java -d main
:ProjectCreate /home/krajah/TestProject/module2 -n java -d main module1
Once you have those projects created, then the pom.xml will be sitting
at the root of the project, allowing you to do the following to update
or .classpath file:
- First, make sure you perform the one time task of setting the
location of the maven repo in your workspace:
$ vim pom.xml
:MvnRepo
- Then you can run maven's eclipse command
$ mvn eclipse:eclipse
- And lastly, force the .classpath file to reload
$ vim .classpath
:w
http://eclim.sourceforge.net/guides/java/maven/mvn/classpath.html
http://maven.apache.org/guides/mini/guide-ide-eclipse.html
> - File search uses classpath file. Should we edit the classpath file
> to limit the search to certain folders or is there any filter option?
Can you give me an example of the kind of filtering you would like,
along with the actual functionality you are referring to (:JavaSearch,
code completion, ect.)?
> - Is there a way I can specify the name of a project?
Yes, if the project is not in eclipse workspace:
:ProjectCreate /home/krajah/TestProject/main -n java -p my_main
If the project is in the eclipse workspace, then it must have the same
name as the project's root directory. This is an eclipse restriction.
> - I use VIM code completion. The preview pane pops up if there is more
> than one match. If I close it can I bring it back on-demand? Eclipse
> displays a window showing the Javadoc, it will be good to have this
> feature as part of VIM preview pane.
The preview pane is a part of vim's core completion support, eclim
simply feeds it the necessary data. So currently the preview pane is
limited by what vim provides.
As for showing the javadocs, I would love to, but the performance hit
is too great. The vim completion support expects all the data
(completion text, description, etc.) to be supplied all at once, but
retrieving the javadocs for a large set of completion results was
painfully slow. Back when I was first implementing code completion in
eclim and Bram was working out the finer details of code completion
support in the vim 7 alphas and betas, I suggested/asked[1] for the
ability to lazily retrieve the completion description (like eclipse
does internally), but my attempt to convince him was unsuccessful.
[1] http://tech.groups.yahoo.com/group/vimdev/message/43114
--
eric
Kannan Rajah
1. mvn eclipse:eclipse by itself is designed to create the .project and .classpath files. Unfortunately, eclim does not recognize projects files that are created outside it. I feel this shouldn't be the case. If I have existing Eclipse project files I should be able to point eclim to them. With the current implementation, I issue CreateProject and then run mvn eclipse:eclipse. But I should admit that this does achieve the end-result.
2. In the given example, if I specify module1 to be dependent on main (in maven terms, main is parent of module1 and not dependent), then there are 2 ways to reach a source file in module1. This causes duplicate entries in file searches (:LocateFile). But this may be a limitation of Eclipse itself. If you notice, mvn eclipse:eclipse does not create project and classpath files for modules with packaging = pom. Maybe this is to avoid the stated duplication problem. In this case what would be a good solution? Maybe I can manually edit the classpath files and get the entries for source path from 'main'. The only reason for desiring a project for 'main' is so that we can get access to the pom.xml file located at its head while doing :LocateFile. If its too much of a hassle I would as well not create a project for 'main'. Just create projects for modules with actual sources (packaging = jar).
3. I recently moved to 1.4.4 and found :LocateFileEdit replaced by :LocateFile. The good thing is it has this nice drop down box with suggestions. I had requested for this feature during the initial releases. Thanks Eric! But I find some serious limitations or at-least I do not find documentation to achieve certain functionalities.
3.1 It always looks at the currently opened file and determines the project and strictly uses its dependency tree to search for files. It ignores other opened projects. This is bad! I believe Eclipse searches for the file in all opened projects. I usually type 'vim' and then open files from there. Now I have to open a valid file inside some project to navigate to other files. Even worse, there is no way for me to navigate to some file in an unrelated project.
3.2 :LocateFile does not seem to allow regular expression searches
3.3 In command line mode I could use the vim buffer to search for recently typed queries (by using Up/Down arrow keys). But when I go into the drop down mode, I do not have access to the recently searched items. Another related difficulty in the drop down mode is that the arrow keys do not seem to have the expected behavior of scrolling up and down. Is it possible to enable it? Using tab was not intuitive for me.
4. Most of the times JavaSearch results in OutOfMemory errors. I started facing this problem only recently. Is this an inherent limitation or is there a way for me to configure the heap size?
--
Kannan
Eric Van Dewoestine
> Sorry for late reply. I was out on vacation. I tried out your suggestions
> for Maven integration. I would like to point out some limitations/issues.
>
> 1. mvn eclipse:eclipse by itself is designed to create the .project and
> .classpath files. Unfortunately, eclim does not recognize projects files
> that are created outside it. I feel this shouldn't be the case. If I have
> existing Eclipse project files I should be able to point eclim to them. With
> the current implementation, I issue CreateProject and then run mvn
> eclipse:eclipse. But I should admit that this does achieve the end-result.
Eclim does recognize existing projects. Perhaps your existing
projects are just located in a non default workspace location. Please
see the faq regarding configuration of the workspace path.
http://eclim.sourceforge.net/vim/faq.html
> 2. In the given example, if I specify module1 to be dependent on main (in
> maven terms, main is parent of module1 and not dependent), then there are 2
> ways to reach a source file in module1. This causes duplicate entries in
> file searches (:LocateFile). But this may be a limitation of Eclipse itself.
:LocateFile shouldn't return duplicate entries unless there are 2
physical resources of the same name (perhaps one in each project).
Can you give me a small reproducible test case where :LocateFile
returns a duplicate?
> If you notice, mvn eclipse:eclipse does not create project and classpath
> files for modules with packaging = pom. Maybe this is to avoid the stated
> duplication problem. In this case what would be a good solution?
I'm afraid that my maven knowledge is very limited, so again, a
concrete example would help me to understand and diagnose the issue.
> Maybe I can
> manually edit the classpath files and get the entries for source path from
> 'main'. The only reason for desiring a project for 'main' is so that we can
> get access to the pom.xml file located at its head while doing :LocateFile.
> If its too much of a hassle I would as well not create a project for 'main'.
> Just create projects for modules with actual sources (packaging = jar).
>
> 3. I recently moved to 1.4.4 and found :LocateFileEdit replaced by
> :LocateFile. The good thing is it has this nice drop down box with
> suggestions. I had requested for this feature during the initial releases.
> Thanks Eric! But I find some serious limitations or at-least I do not find
> documentation to achieve certain functionalities.
>
> 3.1 It always looks at the currently opened file and determines the
> project and strictly uses its dependency tree to search for files. It
> ignores other opened projects. This is bad!
That's a matter of perspective. What is bad for one is good for
another. In my case, searching the entire workspace by default would
be "bad".
> I believe Eclipse searches for
> the file in all opened projects. I usually type 'vim' and then open files
> from there. Now I have to open a valid file inside some project to navigate
> to other files. Even worse, there is no way for me to navigate to some file
> in an unrelated project.
I'll create some sort of configuration for setting whether it
searches:
- just the current project
- the current project and all dependencies
- the entire workspace.
Perhaps I'll also let it default to the entire workspace when you're
not currently editing a file in a project.
> 3.2 :LocateFile does not seem to allow regular expression searches
Correct. It has been a while since I implemented the feature, so I'll
have to take a look to see if supporting regular expressions makes
sense. If you have some examples where you feel regular expression
support is necessary, please provide them.
> 3.3 In command line mode I could use the vim buffer to search for recently
> typed queries (by using Up/Down arrow keys). But when I go into the drop
> down mode, I do not have access to the recently searched items. Another
> related difficulty in the drop down mode is that the arrow keys do not seem
> to have the expected behavior of scrolling up and down. Is it possible to
> enable it? Using tab was not intuitive for me.
I'll add <up>/<down> support for navigating the results.
> 4. Most of the times JavaSearch results in OutOfMemory errors. I started
> facing this problem only recently. Is this an inherent limitation or is
> there a way for me to configure the heap size?
You can increase the eclipse heap size by specifying the necessary jvm
args when starting eclimd, for example:
$ eclimd -Xmx256M
You can also try adding the settings your eclipse.ini as explained
here:
http://wiki.eclipse.org/FAQ_How_do_I_increase_the_heap_size_available_to_Eclipse%3F
--
eric
Kannan Rajah
Eclim not recognizing existing projects: I have configured my workspace in eclimrc. The actual project and classpath files are outside the workspace directory. As you mentioned that could be the reason. Sorry I don't have a clear understanding. It will be helpful if you can answer the following questions:
1. When I create a project using :ProjectCreate, Eclim associates this project with the configured workspace.
2. I want to maintain a single workspace and have all my related projects under it. In that case if I had created some projects outside Eclim (using maven), then are they automatically associated with my workspace? If so then why is Eclim having a problem in identifying them. If not, under what workspace are they getting created?
Let me clarify my thoughts on the file search being limited to current project. I totally agree that we should not search the entire workspace for a matching file. But I feel it is ok to search within opened projects. Eclipse has the same behavior. Also, the search path could be:
1. Current project
2. Dependent projects
3. Other opened projects
4. Error with message: Unable to find file in any of opened projects
This way we do not incur the overhead of searching for a file in some random project when it is available right under the hood.
Regular expression support in LocateFile: If I type <MyFile.java>, I want it to give me the exact match as first choice. I am not sure if the current implementation guarantees this. There may be files like AnotherMyFile.java. This can show up in the list but not as first. Even better if we have an option like Exact match, Fuzzy match. Most of the times we know the exact file name and so we are not really interested in all the substring matches. Here is my opinion:
1. By default, look for an exact match
2. If the pattern contains regular expressions like '*' only then do a fuzzy match. Or you can provide a different function like FuzzyLocate that does all substring matches. It will be really cool if its smart enough to display the results in the order of maximum substring length matched.
--
Kannan
- Show quoted text -
Eric Van Dewoestine
> I will spend some time tonight to create an example for the duplication
> problem.
> Eclim not recognizing existing projects: I have configured my workspace in
> eclimrc. The actual project and classpath files are outside the workspace
> directory. As you mentioned that could be the reason. Sorry I don't have a
> clear understanding. It will be helpful if you can answer the following
> questions:
>
> 1. When I create a project using :ProjectCreate, Eclim associates this
> project with the configured workspace.
> 2. I want to maintain a single workspace and have all my related projects
> under it. In that case if I had created some projects outside Eclim (using
> maven), then are they automatically associated with my workspace? If so then
> why is Eclim having a problem in identifying them. If not, under what
> workspace are they getting created?
projects. I'm almost positive that it is limited to creating project
artifacts (.project, .classpath), but it is up to the user to create
or import the project in eclipse. Running :ProjectCreate should have
the same effect as creating the project in eclipse, but there
currently is no eclim equivalent for importing a project.
> Let me clarify my thoughts on the file search being limited to current
> project. I totally agree that we should not search the entire workspace for
> a matching file. But I feel it is ok to search within opened projects.
> Eclipse has the same behavior. Also, the search path could be:
>
> 1. Current project
> 2. Dependent projects
> 3. Other opened projects
> 4. Error with message: Unable to find file in any of opened projects
>
> This way we do not incur the overhead of searching for a file in some random
> project when it is available right under the hood.
(g:EclimLocateFileScope) which defaults to the existing behavior of
searching the current project and all dependencies. However if you
set that variable to 'workspace', then all open projects will be
searched. I also added an additional condition where if you invoke
:LocateFile outside of a project, and your search scope is limited to
a project + dependencies, then you'll be prompted as to whether you
want to search the entire workspace or not (if your scope is already
'workspace', then no prompt is necessary).
> Regular expression support in LocateFile: If I type <MyFile.java>, I want it
> to give me the exact match as first choice. I am not sure if the current
> implementation guarantees this. There may be files like AnotherMyFile.java.
> This can show up in the list but not as first. Even better if we have an
> option like Exact match, Fuzzy match. Most of the times we know the exact
> file name and so we are not really interested in all the substring matches.
> Here is my opinion:
>
> 1. By default, look for an exact match
> 2. If the pattern contains regular expressions like '*' only then do a fuzzy
> match. Or you can provide a different function like FuzzyLocate that does
> all substring matches. It will be really cool if its smart enough to display
> the results in the order of maximum substring length matched.
invocation whose primary purpose is to be a fuzzy matcher. It sounds
like for the use case you've described, you want the other flavor,
which is :LocateFile with an argument, whose purpose it to be a more
exact or user defined pattern matcher, like so:
:LocateFile MyFile.java
:LocateFile org/me/**/*MyFile.java
Currently, the argument that it accepts is intended to be a glob like
pattern (using *, **, and ?), but I just committed changes allowing a
sort of a hybrid so you can safely do any of the following:
:LocateFile MyFile.java
:LocateFile org/**/*MyFile.java
:LocateFile \bMyFile.java
:LocateFile MyFile.*\.java
:LocateFile (Another)?MyFile.java
So, the result is that a single or double star will essentially expand
to .*? and .* respectively, and the rest will be interpreted as
perl/java compatible regex syntax.
eric
Kannan Rajah
Consider the following code structure:
/home/krajah/TestProject/main
/home/krajah/TestProject/main/module
There is a pom file at the head of each directory. Create the following projects:
:ProjectCreate /home/krajah/TestProject/main -p MAIN -n java
:ProjectCreate /home/krajah/TestProject/module -p MODULE1 -n java -d main
/MAIN/module1/MyTest.java
/MODULE/MyTest.java
Two final comments on LocateFile:
1. You had mentioned that we use LocateFile with argument for an exact match. Let me clarify what I meant by exact match. I was referring to unix style command completion. I would still like to use the no-argument LocateFile, type in MyFile and see suggestions like MyFile.java, MyFileAgain.java, etc. instead of AnotherMyFile.java. The current argument based LocateFile forces me to type the entire file name. You should be knowing how long and descriptive typical Java file names are
. That's why I requested if we can have another command that behaves like :LocateFile<CR> but displays suggestions like unix command completion.2.Thanks for your efforts to incorporate file search across projects. I just wanted to know if I configure workspace as search option, then is there any particular sequence in which the search happens? It will be a good optimization if it first searches the current project, then its dependent projects and finally other open projects.
--
Kannan
Eric Van Dewoestine
>
> Here is a way to reproduce the duplication problem. I should state that this duplication happens in Eclipse too.
>
> Consider the following code structure:
> /home/krajah/TestProject/main
> /home/krajah/TestProject/main/module
>
> There is a pom file at the head of each directory. Create the following projects:
>
> :ProjectCreate /home/krajah/TestProject/main -p MAIN -n java
> :ProjectCreate /home/krajah/TestProject/module -p MODULE1 -n java -d main
>
> Let us consider a file 'MyFile.java' under module. Clearly the MAIN project has access to this file and so does MODULE. When we search for this file using :LocateFile<CR>, we will see 2 suggestions, one under project MAIN and one under MODULE.
>
> /MAIN/module1/MyTest.java
> /MODULE/MyTest.java
Ah so you have a project nested in another one. I'm actually surprised
that eclipse allows that.
The issue is now fixed though on the trunk.
> Two final comments on LocateFile:
> 1. You had mentioned that we use LocateFile with argument for an exact match. Let me clarify what I meant by exact match. I was referring to unix style command completion. I would still like to use the no-argument LocateFile, type in MyFile and see suggestions like MyFile.java, MyFileAgain.java, etc. instead of AnotherMyFile.java. The current argument based LocateFile forces me to type the entire file name. You should be knowing how long and descriptive typical Java file names are . That's why I requested if we can have another command that behaves like :LocateFile<CR> but displays suggestions like unix command completion.
I added another setting to turn off the fuzzy matching
:let g:EclimLocateFileFuzzy = 0
to make the no arg version behave just like the arg version.
Disabling the fuzzy matching should give you the behavior that you're
looking for, but additional feedback is more than welcome.
> 2.Thanks for your efforts to incorporate file search across projects. I just wanted to know if I configure workspace as search option, then is there any particular sequence in which the search happens? It will be a good optimization if it first searches the current project, then its dependent projects and finally other open projects.
I've been tweaking with sorting of workspace wide searches it's been
working pretty well in my testing, but feel free to give the svn trunk
a shot and let me know how well it works for you.
--
eric
Kannan Rajah
Kannan