viktor/dot_files
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Adding new stuff

Browse source
This commit is contained in:
Viktor Barzin 2017-10-08 12:00:02 +01:00
parent 39ee792ad4
commit a410da0e04
722 changed files with 331 additions and 189 deletions
Download patch file Download diff file Expand all files Collapse all files

70
vim-plugins/bundle/eclim/doc/vim/java/android.txt Normal file
View file

@ -0,0 +1,70 @@
*vim-java-android.html*
Android
*******
Creating a project
==================
Creating an android project is the same as creating a regular java
project, but you use the android nature instead:
>
:ProjectCreate /path/to/my_project -n android
<
This will result in a series of prompts for you to input your
project's information:
Note: at any point in this process you can use Ctrl+C to cancel the
project creation.
1. First you will be asked to choose the target android platform.
If you have only one platform installed on your system, this prompt
will be skipped and that platform will be used when creating the
project. If you have no platforms installed then you will receive
an error directing you to install a platform using the Android SDK
Manager. If you install a new platform you will need to either
restart eclipse/eclimd or run the eclim supplied |:AndroidReload|
command.
2. Next you will be asked to supply a package name (Ex:
com.mycompany.myapp).
3. Then you will need to supply a name for your application.
4. The next prompt will ask you if you are creating a library
project or not. Most likely you are not, so type 'n' here to
proceed.
5. Lastly, if you are not creating a library project, you will be
asked whether or not you want to have a new android activity
created for you and if so, you will be asked for the name of that
activity.
Once you've finished supplying the necessary information, your android
project will be created. An android project is simply a specialized
java project, so you can now leverage all the eclim provided java
functionality (vim-java-index) while developing your app.
Commands
========
*:AndroidReload*
:AndroidReload - Reloads the Android SDK environment in the running
eclimd/eclipse instance. Useful if you've made changes to the SDK
outside of eclipse (installed a new target platform, etc).
Configuration
=============
Eclim Settings (vim-settings)
*com.android.ide.eclipse.adt.sdk*
- com.android.ide.eclipse.adt.sdk - Sets the path to your system's
android sdk install.
vim:ft=eclimhelp

219
vim-plugins/bundle/eclim/doc/vim/java/ant.txt Normal file
View file

@ -0,0 +1,219 @@
*vim-java-ant.html*
Ant
***
Running
=======
For those that use Vim as an editor and ant as a build tool, is is
common to set your Vim 'makeprg' option to execute ant so that you may
navigate compilation errors via Vim's quickfix functionality.
Eclim utilizes this same paradigm to provide users with ant execution
functionality from any file without any of the setup required by Vim.
*:Ant*
Eclim provides the following command:
:Ant [<target> ...]
which performs the following steps:
- Saves any previous 'makeprg' and 'errorformat' option settings so
that you can define your own settings for the :make command.
- Sets 'makeprg' to execute ant with the -find option so that it
will search for your build.xml file in the current directory or in a
parent directory.
- Sets 'errorformat' to recognize the following errors:
- javac errors.
- javadoc errors.
- jasper jsp compilattion errors.
- junit errors / failures.
- cactus errors / failures.
- Executes :make.
- Restores your previous 'makeprg' and 'errorformat' option
settings.
Additionally, if g:EclimMakeLCD (|vim-core-eclim#g:EclimMakeLCD|) is
enabled (which it is by default), then the execution of ant will be
performed from the current buffer's project root directory, ensuring
that ant's build file discovery method is performed from the buffer's
working directory and not your own.
Note: :Ant also supports use of '!' (:Ant!) just like :make does,
which tells Vim not to jump to the first error if one exists.
The :Ant command also has the added benefit of command completion.
>
:Ant com<Tab>
:Ant compile
<
Warning: If your ant file has a lot of imports, then the command
completion may be slow as Eclipse parses all the imports when
creating the ant model. You will notice the same slow behavior when
using Eclipse directly to perform ant code completion.
Code Completion
===============
Ant code completion uses the standard Vim code completion mechanism
(vim-code_completion) like so:
>
<ja<Ctrl-X><Ctrl-U>
<jar de<Ctrl-X><Ctrl-U>
<jar destfile="${bas<Ctrl-X><Ctrl-U>
<jar destfile="${basdir
...
<
Screenshot of completion in action:
[image]
Warning: If your ant file has a lot of imports, then the code
completion may be slow as Eclipse parses all the imports when
creating the ant model. You will notice the same slow behavior when
using Eclipse directly.
Validation
==========
When editing an ant xml file eclim will default to validating the file
when it is written. Any errors will be added to the current window's
location list (:help location-list) and their corresponding line
number noted via Vim's sign functionality.
Currently the Eclipse ant file validation isn't as robust as one might
hope. It doesn't validate that element attributes are correct, that
child elements are valid, etc., but it does perform the following:
- If a default target is specified, validate that it exists and that
the target dependencies exist.
- Check for missing dependencies.
- Check for circular dependencies.
Eclim also combines the above validation with xml validation
(vim-xml-index#xml-validation) to validate that the ant file is well
formed.
If you do not want your ant files validated automatically when saved,
you can set the |g:EclimAntValidate| variable described in the
configuration section below.
*:Validate_ant*
Whether or not auto validation has been enabled, eclim also exposes
the command :Validate to manually execute the validation of the ant
file.
*:AntDoc*
Documentation Lookup
====================
When editing an ant build file eclim defines a command named :AntDoc
which will attempt to lookup and open in your configured browser
(|vim-core-eclim#g:EclimBrowser|) the documentation for the element
under the cursor or, if supplied, the element passed to it.
This command will only lookup element names, not attribute names or
values.
By default this plugin is configured to find all the standard ant
tasks, types, etc, as well as those defined by the antcontrib
(http://ant-contrib.sourceforge.net) project.
*:AntUserDoc*
If you have other tasks that you wish to add to this plugin, you can
do so by defining the global variable g:EclimAntUserDocs. The value of
this variable is expected to be a map of element names to the url
where the documentation for that element can be found. The url also
supports a substitution variable, <element> which will be substituted
with the lower case version of the element name.
The following is an example which adds the tasks from the apache
cactus project.
>
let s:cactus =
\ 'http://jakarta.apache.org/cactus/integration/ant/task_<element>.html'
let g:EclimAntUserDocs = {
\ 'cactifywar' : s:cactus,
\ 'cactifyear' : s:cactus,
\ 'cactus' : s:cactus,
\ 'runservertests' : s:cactus,
\ 'webxmlmerge' : s:cactus,
\ }
<
Configuration
=============
Vim Settings (vim-settings)
*g:EclimAntCompilerAdditionalErrorFormat*
- g:EclimAntCompilerAdditionalErrorFormat (Default: '') - Since
there are many more ant tasks beyond javac, javadoc, etc., eclim
provides this variable as a means to add error format information
for any additional ant tasks that you may be using.
Example: Adding support for xslt
>
let g:EclimAntCompilerAdditionalErrorFormat =
\ '\%A%.%#[xslt]\ Loading\ stylesheet\ %f,' .
\ '\%Z%.%#[xslt]\ %.%#:%l:%c:\ %m,'
<
Note: The xslt task is a bit flaky when it comes to reporting the
file name on errors, so the above format will catch successful
runs as well. If anyone has a better solution, please submit it.
*g:EclimAntErrorsEnabled*
- g:EclimAntErrorsEnabled (Default: 0) - When non-zero, build file
error messages will be added to vim's quickfix if encountered during
:Ant invocations. Disabled by default because it's difficult to
distinguish between actual issues with the build file (invalid
property, task, etc.) and build failure messages which occur under
normal usage (junit task failed due to test failure, javac failures
due to compile error, etc.) leading to false positives.
*g:EclimAntValidate*
- g:EclimAntValidate (Default: 1) - If set to 0, disables ant xml
validation when saving the file.
Suggested Mappings
==================
Here are some mappings for the ant funtionality provided by eclim. To
make use of these mappings, simply create a ftplugin file for ant and
place your mappings there (:help ftplugin-name).
- Lookup and open the documentation for the ant element under the
cursor with <enter>.
>
noremap <silent> <buffer> <cr> :AntDoc<cr>
<
vim:ft=eclimhelp

371
vim-plugins/bundle/eclim/doc/vim/java/classpath.txt Normal file
View file

@ -0,0 +1,371 @@
*vim-java-classpath.html*
Eclipse Classpath Editing
*************************
Source code completion, searching, auto imports, all rely on a
properly configured classpath. When you first create a project, a
.classpath file is created in the project's root directory. If you
created the project on an existing code-base, eclim will attempt to
setup the .classpath file with any source code directories or
libraries in the project.
Regardless of the state of your project you will at some point need to
update the classpath. The primary method of doing so, is to directly
edit the .classpath to add, update, or remove entries as needed. To
help you do this, eclim provides several commands to ease the creation
of new classpath entries and variables.
Note: All of the commands described below are only available while
editing the .classpath file in vim.When you write the .classpath
file, Vim will issue a command to the eclim server to update the
project's classpath, and will report any errors via vim's location
list (:help location-list).In addition to directly editing the
.classpath file, you may also use maven's support for maintaining
the eclipse classpath. For users who use ivy
(http://jayasoft.org/ivy), eclim also provides a means to auto
update the eclipse classpath when saving changes to your ivy.xml.
*:NewSrcEntry_java*
- :NewSrcEntry <dir> - Adds a new entry for a source code directory
relative to the project's root directory.
>
<classpathentry kind="src" path="src/java"/>
<
This command supports command completion of the directory relative
to the .classpath file.
*:NewProjectEntry_java*
- :NewProjectEntry <project> - Adds a new entry for a dependency on
another project.
>
<classpathentry exported="true" kind="src" path="/a_project"/>
<
This command supports command completion of the project name.
*:NewJarEntry_java*
- :NewJarEntry <file> [<src_path> <javadoc_path>] - Adds a new entry
for a jar file dependency. If the jar file is not in a folder under
the project root, you must use an absolute path (apparent limitation
with Eclipse).
>
<classpathentry exported="true" kind="lib" path="lib/commons-beanutils-1.8.3.jar"/>
<
You may optionally supply the path to the source for this jar and
the entry created will include the sourcepath attribute:
>
:NewJarEntry lib/commons-beanutils-1.8.3.jar lib/commons-beanutils-1.8.3-sources.jar
<
>
<classpathentry kind="lib" path="lib/commons-beanutils-1.8.3.jar"
sourcepath="lib/commons-beanutils-1.8.3-sources.jar"/>
<
In addition to the source path you can all supply the path to the
javadocs:
>
:NewJarEntry lib/commons-beanutils-1.8.3.jar lib/commons-beanutils-1.8.3-sources.jar lib/commons-beanutils-1.8.3-javadoc.jar
<
>
<classpathentry kind="lib" path="lib/commons-beanutils-1.8.3.jar"
sourcepath="lib/commons-beanutils-1.8.3-sources.jar">
<attributes>
<attribute name="javadoc_location" value="jar:platform:/resource/my_project/lib/commons-beanutils-1.8.3-javadoc.jar"/>
</attributes>
</classpathentry>
<
*:NewVarEntry_java*
- :NewVarEntry <VAR/file> [<src_path> <javadoc_path>] - Just like
NewJarEntry except an Eclipse "var" entry is created. When a jar
entry references an absolute path, you should instead use a var
entry. The var entry allows you to define a base dir as a variable
(ex. USER_HOME = /home/username), and then reference files relative
to that variable.
>
<classpathentry exported="true" kind="var" path="USER_HOME/lib/hibernate-4.0.jar"/>
<
This allows you to share .classpath files with other developers
without each having a local copy with environment specific paths.
To add new base classpath variables, you can edit
$ECLIPSE_HOME/plugins/org.eclim_version/classpath_variables.properties
By default, a USER_HOME variable is created that defaults to the
java System property "user.home" and you can add more as needed.
This command supports command completion of Eclipse variable names
as well as the files and directories beneath the path the variable
represents.
To manage the classpath variables, eclim also provides the following
commands.
*:VariableList*
- :VariableList - Lists all the currently available classpath
variables and their corresponding values.
*:VariableCreate*
- :VariableCreate <name> <path> - Creates or updates the variable
with the supplied name.
*:VariableDelete*
- :VariableDelete <name> - Deletes the variable with the supplied
name.
*classpath-src-javadocs*
Source and Javadoc location
===========================
For your var and lib classpath entries, if you didn't do so when you
created the entry, you can configure the location for that entry's
source code and javadocs, like the example below, allowing you to jump
to the source (|:JavaSearch|) or lookup the docs (|:JavaDocSearch|) of
classes, etc found in that library. Note that the javadoc location
must be a url, whether it be on the local file system (file:, jar:file
(jar:file):) or remote (http:).
>
<classpathentry exported="true" kind="lib" path="lib/hibernate-4.0.jar"
sourcepath="<path>">
<attributes>
<attribute name="javadoc_location" value="file:<javadoc_dir>"/>
</attributes>
</classpathentry>
<
Note: If your javadoc location is a jar in your workspace (in the
curent project or another project), then the url must be in the form
(where <project_name> is replaced with your project's name):>
jar:platform:/resource/<project_name>/path/to/javadoc.jar!/
<
If the jar file is outside of your workspace, then it would be in
the form:>
jar:file:/your/absolute/path/to/javadoc.jar!/
<
*classpath-maven*
Maven
=====
Maven (http://maven.apache.org) comes bundled with an Eclipse plugin
that allows you to easily maintain your .classpath file based on your
pom.xml (or project.xml for maven 1.x users).
Note: For additional information on the Eclipse plugin from maven,
you may visit their online documentation for maven 1.x
(http://maven.apache.org/maven-1.x/plugins/eclipse/) or maven 2.x
(http://maven.apache.org/guides/mini/guide-ide-eclipse.html).
*:MvnRepo* *:MavenRepo*
- Initial Setup
To initialize maven's support for updating the eclipse classpath you
first need to set the M2_REPO (or MAVEN_REPO for 1.x) classpath
variable in the Eclipse workspace by executing the following command
in vim:
maven 2.x:
>
:MvnRepo
<
maven 1.x:
>
:MavenRepo
<
- Updating your .classpath
Once you have performed the initial setup, updating the Eclipse
.classpath file is as easy as executing the following at a command
line:
maven 2.x:
>
mvn eclipse:eclipse
<
maven 1.x:
>
maven eclipse
<
or in Vim:
maven 2.x:
>
:Mvn eclipse:eclipse
<
maven 1.x:
>
:Maven eclipse
<
*classpath-maven-pom*
For maven 2.x users, eclim also provides support for auto updating
the .classpath for your project every time you save your pom.xml
file. Any entries found in the pom.xml that are not in the
.classpath will be added, any entries that differ in version will be
updated, and any stale entries deleted.
Note: This behavior can be disabled by adding the following
setting to your vimrc:>
let g:EclimMavenPomClasspathUpdate = 0
<
Note: This feature simply updates the entries in your project's
.classpath file, it does not download any newly added jars. When
you'd like maven to download those new jars, you can run the
following from the command line:>
mvn dependency:resolve
<
or from within Vim:>
:Mvn dependency:resolve
<
*classpath-ivy*
Ivy
===
For users of ivy (http://jayasoft.org/ivy), eclim provides support for
auto updating the .classpath for your project every time you save your
ivy.xml file. Any entries found in the ivy.xml that are not in the
.classpath will be added, any entries that differ in version will be
updated, and any stale entries deleted.
*:IvyRepo*
- Initial Setup
Before you can start utilizing the auto updating support, you must
first set the location of your ivy repository (ivy cache). This is
the directory where ivy will download the dependencies to and where
eclipse will then pick them up to be added to your project's
classpath.
To set the repository location you can use the :IvyRepo command
which is made available when editing an ivy.xml file.
>
:IvyRepo ~/.ivy2/cache/
<
If you fail to set this prior to writing the ivy.xml file, eclim
will emit an error notifying you that you first need to set the
IVY_REPO variable via this command.
- Updating your .classpath
Once you have performed the initial setup, updating the Eclipse
.classpath file is as easy as saving your ivy.xml file (:w) and
letting eclim do the rest.
Note: This behavior can be disabled by adding the following
setting to your vimrc:>
let g:EclimIvyClasspathUpdate = 0
<
Note: This feature will update your project's .classpath file
accordingly, but it will not download any newly added jars. For
that you'll need to have a target in your ant build file that will
force ivy to download dependencies. Something like the example
from the ivy docs:>
<target name="resolve" description="--> retrieve dependencies with ivy">
<ivy:retrieve/>
</target>
<
You can then run this target from the command line:>
ant resolve
<
or from within Vim>
:Ant resolve
<
- Preserving manually added entries
When utilizing the ivy support, eclim will attempt to remove any
stale entries from your .classpath file. If you have some manually
added entries, these may be removed as well. To prevent this you
can add a classpath entry attribute notifying eclim that the entry
should be preserved.
Ex.
>
<classpathentry kind="lib" path="lib/j2ee-1.4.jar">
<attributes>
<attribute name="eclim.preserve" value="true"/>
</attributes>
</classpathentry>
<
vim:ft=eclimhelp

35
vim-plugins/bundle/eclim/doc/vim/java/complete.txt Normal file
View file

@ -0,0 +1,35 @@
*vim-java-complete.html*
Java Code Completion
********************
Java code completion uses the standard Vim code completion mechanism
(vim-code_completion) like so:
>
System.o<Ctrl-X><Ctrl-U>
System.out.pri<Ctrl-X><Ctrl-U>
<
Screenshot of completion in action:
[image]
Configuration
=============
Vim Settings (vim-settings)
*g:EclimJavaCompleteCaseSensitive*
- g:EclimJavaCompleteCaseSensitive (Default: !&ignorecase) - When
set to a value greater than 0, eclim will filter out completions
that don't start with the same case base that you are attempting to
complete (the base and the suggested completion must have the same
case).
vim:ft=eclimhelp

262
vim-plugins/bundle/eclim/doc/vim/java/debug.txt Normal file
View file

@ -0,0 +1,262 @@
*vim-java-debug.html*
Java Debugging
**************
*:JavaDebugStart*
Starting a debug session
=========================
Before starting a debug session from vim you first need to do a couple
things:
1. Start your java program with the debugging hooks enabled:
>
$ java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1044 \
-classpath ./bin org.test.debug.Main
<
2. Start vim with the --servername argument (eclimd currently sends
debugger updates to vim using vim's remote invocation support):
>
$ vim --servername debug ...
<
Note: The server name you choose doesn't matter as long as you don't
have another vim instance running with that same name.
Once you've got your java program running and vim started with a
servername, you can then start your debug session using the
:JavaDebugStart command. This command requires the hostname/IP and the
port number on which the debug server is running.
>
:JavaDebugStart localhost 1044
<
*:JavaDebugBreakpointToggle*
Add/Remove a breakpoint
=======================
To add a breakpoint, simply open the file, position the cursor on the
desired line and run the :JavaDebugBreakpointToggle command. If now
breakpoint exists, one will be created. If a breakpoint does exist,
then :JavaDebugBreakpointToggle will toggle whether that breakpoint is
enabled or not. If you'd like to delete the breakpoint on the current
line instead of disabling it, then run the toggle command with the !
option.
>
" create a breakpoint or toggle whether the current breakpoint is
" enabled/disabled
:JavaDebugBreakpointToggle
" same as the above, but instead disabling an enabled breakpoint,
" delete it instead.
:JavaDebugBreakpointToggle!
<
*:JavaDebugBreakpointsList*
Listing your breakpoints
========================
To view a list of all your breakpoints you can use the
:JavaDebugBreakpointsList command, which by default will list all
breakpoints for the current file, or with the ! suffix, it will list
all breakpoints for the current project and all project dependencies.
>
:JavaDebugBreakpointsList
:JavaDebugBreakpointsList!
<
This will open a new window which displays your breakpoints grouped by
file or by project and file.
Mappings
- <cr> - Jump to the file and line of the breakpoint under the
cursor
- T - Toggles the breakpoint under the cursor, or all breakpoints
under the file or project when used on the class name or project
name.
- D - Deletes the breakpoint under the cursor, or all breakpoints
under the file or project when used on the class name or project
name.
*:JavaDebugBreakpointRemove*
Remove breakpoints
==================
In addition to using the delete mapping provided in the
|:JavaDebugBreakpointsList| window, you can also remove all
breakpoints in the current file using the :JavaDebugBreakpointRemove
command, or with the ! suffix, you can remove all breakpoints in the
current project.
>
:JavaDebugBreakpointRemove
:JavaDebugBreakpointRemove!
<
*:JavaDebugStep*
Step Through the Code
=====================
There are 3 ways to step through code using the :JavaDebugStep command
and an action argument.
- over: Step over current line
- into: Step into a function
- return: Return from current function
>
:JavaDebugStep over
:JavaDebugStep into
:JavaDebugStep return
<
*:JavaDebugStatus*
Status
======
When a debugging session is started, a status window is automatically
opened at the bottom in a horizontal split window. It has 2 panes:
- Debug Threads: The left pane shows active threads along with its
stack frames.
Mappings
- s - Suspend the thread under the cursor.
- S - Suspend all threads.
- r - Resume the thread under the cursor.
- R - Resume all threads.
- B - Open the breakpoints window showing all breakpoints for this
project and dependencies.
- Debug Variables: The right pane shows the variables available for
the thread selected on the left pane. Variables can be seen only for
suspended threads. If there are suspended threads, then one of them
is automatically selected and its variables displayed.
Mappings
- <cr> - Expands the variable. Nested variables are shown in a
tree like structure. To collapse the variable, press <CR> again.
- p - Displays the toString value of the variable under cursor.
This is equivalent to the Details pane in Eclipse.
- B - Open the breakpoints window showing all breakpoints for this
project and dependencies.
If for some reason, the status window is not updated, or you
accidentally closed it, you can manually refresh it by running
:JavaDebugStatus command.
>
:JavaDebugStatus
<
*:JavaDebugStop*
Suspend / Resume
================
In addition to using the mappings provided in the |:JavaDebugStatus|
threads window, you can also suspend and resume threads using the
following commands:
- To suspend the entire debugging session (all threads), run
:JavaDebugThreadSuspendAll from any window.
- To resume the entire debugging session (all threads), run
:JavaDebugThreadResumeAll from any window.
Stop
====
To stop a debug session, you can use the :JavaDebugStop command.
>
:JavaDebugStop
<
*:JavaDebugThreadSuspendAll* *:JavaDebugThreadResume*
*:JavaDebugThreadResumeAll*
Configuration
=============
*g:EclimJavaDebugLineHighlight*
- g:EclimJavaDebugLineHighlight (Default: 'DebugBreak') Highlight
group to use for showing the current line being debugged.
*g:EclimJavaDebugLineSignText*
- g:EclimJavaDebugLineSignText (Default: '•') Text to use on sign
column for showing the current line being debugged.
*g:EclimJavaDebugStatusWinOrientation*
- g:EclimJavaDebugStatusWinOrientation (Default: 'vertical') Sets
the orientation for the splits inside the debug status windows; if
they should be tiled vertically or horizontally. Possible values: -
horizontal - vertical
*g:EclimJavaDebugStatusWinWidth*
- g:EclimJavaDebugStatusWinWidth (Default: 50) Sets the window width
for the splits inside the debug status window. This is only
applicable when the orientation is horizontal.
*g:EclimJavaDebugStatusWinHeight*
- g:EclimJavaDebugStatusWinHeight (Default: 10) Sets the window
height for the splits inside the debug status window. This is only
applicable when the orientation is vertical.
Troubleshooting
===============
- Expanding a variable shows an empty line with just a dot. You
probably haven't pressed the <Enter> key on the variable. Nested
variables are retreived one level at a time from the server to be
performant. Since we are using VIM folds, any mapping that simply
opens a fold will not cause variables to be retrieved.
- A split window is created when stepping into a function
(JavaDebugStep into) from the debug status window. It is not clear
why this is happening. To avoid this problem, run step into command
outside the debug status window.
vim:ft=eclimhelp

79
vim-plugins/bundle/eclim/doc/vim/java/format.txt Normal file
View file

@ -0,0 +1,79 @@
*vim-java-format.html*
Java Source Code Formatting
***************************
Eclim provides the ability to format java source code using the
eclipse formatter selected for your workspace.
Source code formatting is invoked in eclipse using the shortcut
<C-S-F>, or from the Source / Format menu. The eclim equivalent is
invoked using the :JavaFormat command described below.
*:JavaFormat*
- :JavaFormat - Formats the current visual selection (or the current
line, if nothing is selected). To format the whole file, use
:%JavaFormat.
Given the following file:
>
/**
* @return
*
* Service
* for test Eclipse <C-F> formatting.
*/
public
static String
getAbstractService
()
{
if (abstractService == null)
{
throw new RuntimeException( "abstractService isn't initialized !");
}
return abstractService;
}
<
You can execute :%JavaFormat to format the code according to your
eclipse settings.
>
/**
* @return
*
* Service for test Eclipse <C-F> formatting.
*/
public static String getAbstractService() {
if (abstractService == null) {
throw new RuntimeException("abstractService isn't initialized !");
}
return abstractService;
}
<
Configuration
=============
*org.eclim.java.format.strip_trialing_whitespace*
- org.eclim.java.format.strip_trialing_whitespace - When set to
true, all trailing whitespace will be removed when formatting java
code.
Aside from the above configuration, source code formatting is only
configurable via the eclipse GUI. So to make changes to the eclipse
java formatting rules, shutdown eclim, start the eclipse GUI and
configure your settings via:
Preferences ‣ Java ‣ Code Style ‣ Formatter ‣ Active Profile: ‣ Edit
vim:ft=eclimhelp

60
vim-plugins/bundle/eclim/doc/vim/java/import.txt Normal file
View file

@ -0,0 +1,60 @@
*vim-java-import.html*
*:JavaImport*
Automated Imports
*****************
The automated import functionality is pretty straightforward. Simply
place the cursor over the element to import and issue the command:
:JavaImport
and one of the following events will occur:
- If only one matching element is found, its import statement will
be placed in the file.
- If multiple matching elements are found, you will be prompted to
choose the element you wish to import from a list.
- If an element with the same name is already imported, the element
is in java.lang, or the element is in the same package as the
current src file, then no changes will occur.
*:JavaImportOrganize*
In addition to adding imports one by one, you can also add them in
bulk along with the removal of unused imports and the sorting and
formating of all the file's import statements using the command:
:JavaImportOrganize
Configuration
=============
Eclim Settings (vim-settings)
*org.eclipse.jdt.ui.importorder*
- org.eclipse.jdt.ui.importorder (Default: java;javax;org;com) -
Semicolon separated list of package names which specify the sorting
order for import statements. This settings is the same setting used
by the eclipse gui in the "Organize Imports" preference dialog.
*org.eclim.java.import.exclude*
- org.eclim.java.import.exclude (Default: ["^com.sun..*",
"^sunw?..*"]) - List of patterns to exclude from import results.
*org.eclim.java.import.package_separation_level*
- org.eclim.java.import.package_separation_level (Default: 1) - Used
to determine how imports are grouped together (or spaced apart). The
number represents how many segments of the package name to use to
determine equality, where equal imports are grouped together and
separated from other groups with a blank line.
- -1: Use the entire package name. Only imports from the same full
package are grouped together.
- 0: Don't look at any package segments. All imports are grouped
together with no spacing.
- n: Look at the first n segments of the package name.
vim:ft=eclimhelp

57
vim-plugins/bundle/eclim/doc/vim/java/index.txt Normal file
View file

@ -0,0 +1,57 @@
*vim-java-index.html*
Java
****
Features
========
- Eclipse Classpath Editing (vim-java-classpath)
- Java Validation / Correction (vim-java-validate)
- Java Code Completion (vim-java-complete)
- Java Search (vim-java-search)
- Java / Jps (vim-java-java)
- Java Debugging (vim-java-debug)
- Javadoc Support (vim-java-javadoc)
- Java Source Code Formatting (vim-java-format)
- Java Refactoring (vim-java-refactor)
- Java Code Inspection (vim-java-inspection)
- Automated Imports (vim-java-import)
- Type Creation (vim-java-types)
- Method Generation (vim-java-methods)
- Unit Tests (vim-java-unittests)
- Logging (log4j, etc) (vim-java-logging)
- Ant (vim-java-ant)
- Maven (vim-java-maven)
- Android (vim-java-android)
- WEB-INF/web.xml (vim-java-webxml)
Suggested Mappings
==================
Here are some mappings for the java funtionality provided by eclim.
To make use of these mappings, simply create a ftplugin file for java
and place your mappings there (:help ftplugin-name).
- Import the class under the cursor with <leader>i (:h mapleader):
>
nnoremap <silent> <buffer> <leader>i :JavaImport<cr>
<
- Search for the javadocs of the element under the cursor with
<leader>d.
>
nnoremap <silent> <buffer> <leader>d :JavaDocSearch -x declarations<cr>
<
- Perform a context sensitive search of the element under the cursor
with <enter>.
>
nnoremap <silent> <buffer> <cr> :JavaSearchContext<cr>
<
vim:ft=eclimhelp

112
vim-plugins/bundle/eclim/doc/vim/java/inspection.txt Normal file
View file

@ -0,0 +1,112 @@
*vim-java-inspection.html*
Java Code Inspection
********************
*:JavaHierarchy*
Class / Interface Hierarchy
===========================
When viewing a java class or interface you can view the type hierarchy
by issuing the command :JavaHierarchy. This will open a temporary
buffer with an inversed tree view of the type hierarchy with the
current class / interface at the root.
>
public class XmlCodeCompleteCommand
public class WstCodeCompleteCommand
public class AbstractCodeCompleteCommand
public class AbstractCommand
public interface Command
<
Inner classes / interfaces are also supported. Just place the cursor
on the inner class / interface before calling :JavaHierarchy.
While you are in the hierarchy tree buffer, you can jump to the type
under the cursor using one of the following key bindings:
- <cr> - open the type using the (default action).
- E - open the type via :edit
- S - open the type via :split
- T - open the type via :tabnew
- ? - view help buffer
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimJavaHierarchyDefaultAction*
- g:EclimJavaHierarchyDefaultAction (defaults to 'split') -
Determines the command used to open the type when hitting <enter> on
the type entry in the hierarchy buffer.
*:JavaCallHierarchy*
Call Hierarchy
==============
When viewing a java source file you can view the call hierarchy of a
method by issuing the command :JavaCallHierarchy. This will open a
temporary buffer with an inversed tree view of the hierarchy of
callers of the requested method.
>
foo(int) : Object - org.test.SomeClass
bar() : void - org.test.AnotherClass
main() : void - org.test.MainClass
baz(String) : int - org.test.AnotherClass
<
While you are in the hierarchy tree buffer, you can jump to the call
under the cursor using one of the following key bindings:
- <cr> - open the type using the (default action).
- E - open the type via :edit
- S - open the type via :split
- T - open the type via :tabnew
- ? - view help buffer
:JavaCallHierarchy can also be used to view the callees for a method
by invoking the command with a !:
>
:JavaCallHierarchy!
<
By default the call hierarchy (caller and callee) will search across
your entire workspace. If you want to limit the search to just the
current project you can use the scope (-s) option:
>
:JavaCallHierarchy -s project
<
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimJavaCallHierarchyDefaultAction*
- g:EclimJavaCallHierarchyDefaultAction (defaults to 'split') -
Determines the command used to open the file when hitting <enter> on
an entry in the hierarchy buffer.
vim:ft=eclimhelp

109
vim-plugins/bundle/eclim/doc/vim/java/java.txt Normal file
View file

@ -0,0 +1,109 @@
*vim-java-java.html*
Java / Jps
**********
*:Java*
Java
====
To run the configured main class for your project, you may use the
:Java command, which executes java and displays the results in a
temporary buffer.
Note: Please note that this command is not intended to be a full
replacement for the more advance support provided by eclipse, ant,
or maven.
The :Java will locate the main class to run using the following steps:
1. if the first argument is '%' (:Java %) then run the current
class.
2. if the setting org.eclim.java.run.mainclass is set, then use the
value as the fully qualified class name to run.
3. lastly, attempt to locate a class containing a static main
method, if only one is found, use that class.
Configuration
-------------
*org.eclim.java.run.mainclass*
Eclim Settings (vim-settings)
- org.eclim.java.run.mainclass - Fully qualified name of the class
containing the main method.
- org.eclim.java.run.jvmargs - Json formatted list of default jvm
args.
*:JavaClasspath*
Echo the classpath for the current project
------------------------------------------
When editing a java file, eclim provides the command :JavaClasspath
which will echo the project's resolved classpath entries separated by
the system path separator or a supplied delimiter:
>
:JavaClasspath
:JavaClasspath -d \\n
<
If you would like to get the classpath from a script, you can also
call eclim directly:
>
$ $ECLIPSE_HOME/eclim -command java_classpath -p <project_name>
<
*:JavaListInstalls*
Viewing list of known JDKs/JREs installed
-----------------------------------------
To view a list of all the JDKs/JREs that eclipse is aware of, eclim
provides the command :JavaListInstalls.
*:Jps*
Jps (Process Status Tool)
=========================
As of Java 1.5 (Java 5.0), the sun jdk started shipping with some
useful tools for viewing information about running java processes. To
provide quick and easy access to some of the information these
commands provide, eclim exposes the command :Jps.
Note: For more information on the jdk tools you may view the online
documentation
(http://docs.oracle.com/javase/6/docs/technotes/tools/#monitor).
When invoked it will open a window containing information about the
current processes and some links for viewing additional info
(depending upon availability of required tools on your platform).
Example content:
[image]
- Line 1 consists of the process id followed by either the class
name the process was started with or the path to the jar file.
- Lines 2 - 5 contains links that when you hit <enter> on, will open
another window displaying the requested additional info.
- Lines 7 - 13 is a foldable block which contains a list of all the
arguments passed to the main method of the process.
- Lines 15 - 21 is a foldable block which contains a list of all the
arguments passed to the JVM.
vim:ft=eclimhelp

110
vim-plugins/bundle/eclim/doc/vim/java/javadoc.txt Normal file
View file

@ -0,0 +1,110 @@
*vim-java-javadoc.html*
Javadoc Support
***************
*:JavaDocComment*
Commenting
==========
Eclim provides the :JavaDocComment command which will add or update
the javadoc comments for the element under the cursor.
*:JavaDocPreview*
Viewing
=======
While editing java code, if you'd like to view the javadoc of the
element under the cursor, you can run the :JavaDocPreview command
which will open vim's preview window with the element's javadoc
content. In the preview window any links to classes, methods, etc. in
the javadoc will be highlighted and you can view follow those links by
hitting <cr> on the link. You can also use <c-o> to navigate back to
the previous javadoc preview and <c-i> to navigate forward.
*:JavaDocSearch*
Searching
=========
Eclim supports searching of javadocs just like you would search the
source code (vim-java-search).
The only difference is that you use :JavaDocSearch instead of
:JavaSearch.
The results will be displayed in a window and you can simply hit <cr>
on an entry to open it using the browser you configured via
g:EclimBrowser (|vim-core-eclim#g:EclimBrowser|).
The locations of the javadocs are determined via your Eclipse
project's .classpath file. For each library entry you can define a
javadoc attribute that points to the base url of the javadoc (http,
file, etc).
>
<classpathentry kind="lib" path="lib/hibernate-3.0.jar">
<attributes>
<attribute value="http://hibernate.org/hib_docs/v3/api" name="javadoc_location"/>
</attributes>
</classpathentry>
<
If you would like to set the javadoc url for your project's source
files, you will instead need to set the
org.eclipse.jdt.ui.project_javadoc_location option via
|:ProjectSettings|. Also note that the javadocs for your source files
are not generated automatically, so if you would like to use
:JavaDocSearch to open your project's javadocs, you will first need to
generate those javadocs as described in the next section.
*:Javadoc*
Executing javadoc
=================
To run the javadoc utility on your project's source code, you may use
the :Javadoc command, which with no arguments will execute javadoc
against all your project's source code (as specified by any optional
settings described below).
If you wish to run javadoc only against one or more files, you can
supply the project relative paths as arguments to the :Javadoc command
and only those files will be used.
Note: Please note that this command is not intended to be a full
replacement for javadoc support provided by more comprehensive build
tools like ant or maven.
Configuration
=============
Eclim Settings (vim-settings)
- org.eclim.user.name - Used as the name portion of the author tag.
Consult the settings page (vim-settings) for more info.
- org.eclim.user.email - Used as the email portion of the author
tag. Consult the settings page (vim-settings) for more info.
- org.eclim.java.doc.dest (Default: doc) - The project relative
directory where the javadocs with be written to.
- org.eclim.java.doc.packagenames - Optional space separated list of
package names to run javadoc against.
- org.eclim.java.doc.sourcepath - The project relative javadoc
sourcepath to use. This should be a space separated list of project
relative source directories which you want javadoc to be executed
against. When unset, all your configured source directories will be
used.
- org.eclipse.jdt.ui.project_javadoc_location - URL where your
project's javadocs can be found.
vim:ft=eclimhelp

104
vim-plugins/bundle/eclim/doc/vim/java/logging.txt Normal file
View file

@ -0,0 +1,104 @@
*vim-java-logging.html*
Logging (log4j, etc)
********************
Auto import / initialize
========================
While editing a java source file, if you start to create a logging
statement (log. or logger.), the logging plugin will attempt to
perform the appropriate initialization (imports, static variable) for
the configured logging implementation.
Eclim provides a handful of templates for the most widely used
implementations (commons-logging, slf4j, log4j, and jdk). However, if
you happen to use an alternate logging framework, or perhaps a home
grown framework, eclim also provides the means to supply a custom
template. To utilize it, simply set the org.eclim.java.logging.impl
setting to "custom" and add your template to
~/.eclim/resources/jdt/templates/logger.gst. Two variables will be
supplied to your template: var, which is the logger instance variable,
and class, which is the class name of the current class you are
implementing.
Here is an example which eclim uses for its logger implementation:
>
import org.eclim.logging.Logger;
private static final Logger ${var} = Logger.getLogger(${class}.class);
<
After performing the necessary variable substitution, eclim will take
any imports and insert them amongst your existing import statements.
The remaining code will be inserted after your class definition.
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimLoggingDisabled*
- g:EclimLoggingDisabled (Default: 0) - If set to a value greater
than 0, then this plugin will be disabled.
Eclim Settings (vim-settings)
*org.eclim.java.logging.impl*
- org.eclim.java.logging.impl (Default: "commons-logging") -
Determines which logging implementation to use.
Possible values include "commons-logging", "slf4j", "log4j", "jdk",
and "custom".
*org.eclim.java.logging.template*
- org.eclim.java.logging.template (Default: 'logger.gst') -
Determines the name of the template to use for the custom logger.
The name must be a file name relative to
~/.eclim/resources/jdt/templates/.
*log4j*
Log4j
=====
Validation
----------
When editing a log4j xml file eclim will default to validating the
file when it is written. Any errors will be added to the current
window's location list (:help location-list) and their corresponding
line number noted via Vim's sign functionality.
Eclim also combines the above validation with xml validation
(vim-xml-index#xml-validation) to validate that the file is well
formed.
If you do not want your log4j files validated automatically when
saved, you can set the |g:EclimLog4jValidate| variable described in
the configuration section below.
*:Validate_log4j*
Whether or not auto validation has been enabled, eclim also exposes
the command :Validate to manually execute the validation of the file.
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimLog4jValidate*
- g:EclimLog4jValidate (Default: 1) - If set to 0, disables
validation when saving the file.
vim:ft=eclimhelp

51
vim-plugins/bundle/eclim/doc/vim/java/maven.txt Normal file
View file

@ -0,0 +1,51 @@
*vim-java-maven.html*
Maven
*****
*:Maven* *:Mvn*
Running
=======
Much like the provided ant (vim-java-ant) execution functionality,
eclim also provides commands for running maven 1.x or 2.x.
Eclim provides the following commands:
>
:Maven [<goal> ...]
:Mvn [<goal> ...]
<
which perform the following steps:
- Save any previous 'makeprg' and 'errorformat' option settings so
that you can define your own settings for the :make command.
- Set 'makeprg' to execute maven or mvn with the --find option so
that it will search for your pom file in the current directory or in
a parent directory.
- Set 'errorformat' to recognize the following errors:
- javac errors.
- javadoc errors.
- junit errors / failures.
- Execute :make.
- Restore your previous 'makeprg' and 'errorformat' option settings.
Additionally, if g:EclimMakeLCD (|vim-core-eclim#g:EclimMakeLCD|) is
enabled (which it is by default), then the execution of maven will be
performed from the current buffer's project root directory, ensuring
that mavens's build file discovery method is performed from the
buffer's working directory and not your own.
Note that :Mvn MUST have this enabled since maven 2.x no longer has
support for the --find option.
Note: Both :Maven and :Mvn also supports use of '!' (:Maven!) just
like :make does, which tells Vim not to jump to the first error if
one exists.
vim:ft=eclimhelp

258
vim-plugins/bundle/eclim/doc/vim/java/methods.txt Normal file
View file

@ -0,0 +1,258 @@
*vim-java-methods.html*
Method Generation
*****************
*:JavaConstructor*
Constructors
============
:JavaConstructor is a command that will create either an empty
constructor, or one that takes any selected fields as arguments.
For example if you have the following class:
>
public class Foo
{
private int id;
private String name;
}
<
If you were to select the range containing the 'id' and 'name' fields
and issue :JavaConstructor, then you would end up with the following
code.
>
public class Foo
{
private int id;
private String name;
/**
* @param id
* @param name
*/
public Foo(int id, String name) {
this.id = id;
this.name = name;
}
}
<
If you issue the command with no fields selected, then a default empty
constructor is created.
When attempting to create an empty constructor, if the super class
doesn't define a default constructor, but instead has one or more
constructors which takes arguments, then calling :JavaConstructor
without a range will result in the creation of a constructor which
overrides the super class constructor containing the least number of
arguments. Although an empty constructor won't pass code validation,
you can force the creation of one in this case by suffixing the
command with a '!':
>
:JavaConstructor!
<
*:JavaGetSet*
Getters / Setters
=================
- :JavaGetSet - Generates both getters and setters for the field
under the cursor or for all fields in the specified range.
*:JavaGet*
- :JavaGet - Generates getters for the field under the cursor or for
all fields in the specified range.
*:JavaSet*
- :JavaSet - Generates setters for the field under the cursor or for
all fields in the specified range.
Note: If you would like to generate the indexed getter or setter
then you can suffix the appropriate command above with '!' and if
the property is an array, an indexed accessor will be created.>
:JavaGetSet!
<
Given the following file:
>
public class Foo
{
private String name;
private Bar[] bars;
}
<
You can place the cursor on one of the fields and execute :JavaGetSet
to generate the getters and setters for the field. All of the above
commands support ranges as well, so you can use a visual selection or
a numbered range to generate methods for a set of fields.
*:JavaImpl*
Override / Impl
===============
Eclim provides the ability to view all the methods that the current
source file can implement or override according to what interfaces it
implements and classes it extends. From the list of methods you can
then choose which you want to implement or override, and the
appropriate method stub will be inserted into the file.
The first step in the process is to execute :JavaImpl which will open
a Vim window containing a list possible methods to implement /
override and the interface / class which defines those methods.
Here is some example content from a class that extends
java.io.InputStream:
>
com.test.TestStream
package java.io;
class InputStream
public int read()
public int read(byte[])
public int read(byte[], int, int)
public long skip(long)
public int available()
public void close()
public void mark(int)
public void reset()
public boolean markSupported ()
package java.lang;
class Object
public int hashCode()
public boolean equals(Object)
protected Object clone()
public String toString()
protected void finalize()
<
From the newly opened window you can select a method to generate a
stub for by simply hitting <enter> with the cursor over the method
signature.
If you would like to generate stubs for all methods in an interface or
class, then simply hit <enter> with the cursor over the class name and
stub methods will be created for each method in that class or
interface.
This functionality supports outer, inner, and anonymous classes
classes. To view the list of methods to override for an inner or
anonymous class, simply execute :JavaImpl with the cursor somewhere in
the body of the inner or anonymous class.
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimJavaImplInsertAtCursor*
- g:EclimJavaImplInsertAtCursor (Default: 0) - By default eclim will
insert methods you've chosen after all the existing methods, but
before any inner classes. If you enable this setting, then the
methods will instead be inserted near where your cursor was when you
first invoked :JavaImpl.
*:JavaDelegate*
Delegate Methods
================
Eclim supports generation of delegate methods via the :JavaDelegate
command. To utilize this functionality you must first place the cursor
on a global field (in the main source file class or within an inner
class), and then invoke the :JavaDelegate command.
In the following source, you can place the cursor anywhere starting
from the first 'p' in private, to the trailing semicolon, and then
invoke the :JavaDelegate command.
>
private List myList;
<
Invoking this command with the cursor on some other source element
will generate the appropriate error.
Once successfully invoked, the result will be the opening of a lower
window with all the methods that may be inserted that will delegate to
the value of the field.
Here is a section of the content displayed when invoking the command
on a field of type java.util.List like the one above.
>
com.test.TestList.myList
package java.util;
interface List
public abstract int size()
public abstract boolean isEmpty()
public abstract boolean contains(Object)
public abstract Object[] toArray()
...
<
From this newly opened window you can select a method by simply
hitting <enter> with the cursor over the method signature and a
delegate method will be created.
For example, if you hit <enter> on the size() method, then the
following code will be inserted.
>
/**
*/
public int size ()
{
return myList.size();
}
<
If you would like to generate delegate methods for all methods in an
interface or class, then simply hit <enter> with the cursor over the
class name, and delegate methods will be created for each method in
that interface or class.
vim:ft=eclimhelp

171
vim-plugins/bundle/eclim/doc/vim/java/refactor.txt Normal file
View file

@ -0,0 +1,171 @@
*vim-java-refactor.html*
Java Refactoring
****************
*:JavaRename*
Rename
======
The first refactoring that eclim supports is :JavaRename, which can be
used to rename various java elements.
Example:
>
package org.foo.bar;
public class Foo {
public void bar(){
}
}
<
To rename the class from 'Foo' to 'Bar' you simply position the cursor
over the class name 'Foo' and execute:
>
:JavaRename Bar
<
The result of which will the following prompt:
>
Rename "Foo" to "Bar"
([e]xecute / [p]review / [c]ancel):
<
This prompt give you three options:
1. execute: Execute the refactoring without previewing the changes
to be made. The current file and any other changed files open in
the current instance of vim will be reloaded.
2. preview: Preview the changes that the refactoring will perform.
This will open a scratch buffer with a list of changes to be made
along with a link at the bottom to execute the refactoring.
The contents of the preview window will vary depending on what you
are renaming.
If we are renaming 'Foo' to 'Bar' the contents would be like so:
>
other: Rename compilation unit 'Foo.java' to 'Bar.java'
|Execute Refactoring|
<
If we are renaming the method 'bar' to 'foo', the contents would
look like so:
>
|diff|: /home/someuser/workspace/test_java/src/org/foo/bar/Foo.java
|Execute Refactoring|
<
If the first instance, there is not much to preview. Since this
particular class is not referenced anywhere else, the only
operation eclipse will perform, is to rename the file from
'Foo.java' to 'Bar.java' which will also update the class name in
that file.
In the second instance eclipse provides a preview of the actual
changes to the file what will be performed. If the method were
referenced elsewhere, you would see an entry for each file that
would be modified by the refactoring. To actually for a vim diff
split of the changes that will be performed, simple position the
cursor on the diff entry and hit <enter>.
Once you are satisfied with changes that eclipse will perform, you
can then execute the refactoring by positioning the cursor over the
"|Execute Refactoring|" link and hit <enter>.
3. cancel: Cancel the refactoring (Hitting enter without typing a
choice or hitting Ctrl-C will also cancel the refactoring).
Package Renaming
Renaming a package is performed just like renaming any other element.
However, the name you supply to the :JavaRename command must be the
full package name that you are renaming the package to. For example.
In sample java file above, if you place the cursor on the 'org'
portion of the package declaration, you can rename 'org' to 'com' by
running :JavaRename com. If you want to rename the 'foo' package to
'baz' you can do so by running :JavaRename org.baz. Note that if you
were to only supply the name 'baz', the 'foo' package would be moved
to the same level as 'org' and then renamed.
Warning: When renaming a package, the associated directory will also
be renamed in the underlying file system. Eclim will do its best to
reload any files that have moved as a result of the directory
renaming and adjust your current working directory if necessary, but
only for the current vim session. If you have other vim sessions
open with files located in the directory that is renamed, then eclim
will be unable to reload those files in those sessions for you, so
you will have to do so manually. A best practice would be to close
any other vim sessions that might be affected by the renaming of a
package.
*:JavaMove*
Move
====
Eclim also supports moving a top level class or interface from one
package to another using the :JavaMove command.
In this example the current file would be moved from its current
package to the package org.foo:
>
:JavaMove org.foo
<
Like the package renaming described in the previous section, the
argument to :JavaMove must be the full package name you want to move
the current file to.
Refactor Undo/Redo
==================
In the event that you need to undo a refactoring, eclim provides the
:RefactorUndo command. When executed, the last refactoring will be
reverted. If you are unsure what the last refactoring was, the
:RefactorUndoPeek command will print the name of the top most
refactoring on the undo stack.
Eclim also provides the :RefactorRedo and :RefactorRedoPeek commands
which provide the redo counterpart to the undo commands.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimRefactorDiffOrientation_java*
- g:EclimRefactorDiffOrientation (Default: 'vertical') - Specifies
the orientation used when previewing a refactoring and performing a
diff split between the current file contents and the changes to be
performed by the refactoring. Possible values include 'vertical' or
'horizontal'.
vim:ft=eclimhelp

246
vim-plugins/bundle/eclim/doc/vim/java/search.txt Normal file
View file

@ -0,0 +1,246 @@
*vim-java-search.html*
Java Search
***********
*:JavaSearch*
Pattern Search
==============
Pattern searching provides a means to widen a search beyond a single
element. A pattern search can be executed using the command
:JavaSearch -p <pattern> [-t <type> -x <context> -s <scope> -i -a
<action>]
When there is more than 1 result, those results will be placed into
vim's quickfix list (:help quickfix) so that you can easily navigate
them using vim's quickfix commands.
Vim command completion is supported through out the command with the
excption of the pattern to search for.
>
:JavaSearch <Tab>
:JavaSearch -p MyClass* <Tab>
:JavaSearch -p MyClass* -t <Tab>
:JavaSearch -p MyClass* -t all <Tab>
:JavaSearch -p MyClass* -t all -x <Tab>
:JavaSearch -p MyClass* -t all -x declarations
<
- -p <pattern>: The pattern to search for.
Ex.
>
MyClass*
MyClass.someMethod*
<
- -t <type> (Default: type): The type of element to search for where
possible types include
- annotation
- class
- classOrEnum
- classOrInterface
- constructor
- enum
- field
- interface
- method
- package
- type
- -x <context> (Default: declarations): The context of the search,
where possible context values include
- all - All occurrences.
- declarations - Declarations matching the pattern or element.
- implementors - Implementors of the pattern or element.
- references - References of the pattern or element.
- -s <scope> (Default: all): The scope of the search where possible
values include
- all - Search the whole workspace.
- project - Search the current project, dependent projects, and
libraries.
- -i: Ignore case when searching.
- -a: The vim command to use to open the result (edit, split,
vsplit, etc).
Eclim also provides a shortcut when issuing a pattern search for a
type. You may simply invoke :JavaSearch supplying only the pattern.
>
:JavaSearch SomeType
<
To shorten things even more, there is support for camel case searching
as well.
>
:JavaSearch NPE
<
However, please note that camel case searching does not permit wild
card characters ('*', '?').
Element Search
==============
Element searching allows you to place the cursor over just about any
element in a source file (method call, class name, field) and perform
a search for that element. Performing an element search is the same
as performing a pattern search with the exception that you do not
specify the -p option since the element under the cursor will be
searched for instead.
If only one result is found and that result is in the current source
file, the cursor will be moved to the element found.
*:JavaSearchContext*
As a convenience eclim also provides the command :JavaSearchContext.
This command accepts only the optional -a argument described above,
and will perform the appropriate search depending on the context of
the element under the cursor.
- If the cursor is on a class or interface declaration, the command
will search for all classes / interfaces that implement / extend the
element.
- If the cursor is on a method or field declaration, the command
will search for all references to the element.
- Otherwise, it will search for the declaration of the element.
Alternate Searching
===================
For those occasions that you find yourself browsing a third party
source distribution that you want to be able to search without going
through the steps of setting up a project, eclim provides an alternate
searching mechanism. To utilize the alternate searching requires no
change in behavior or commands, but to achieve the best results, you
should know how it works.
The first thing worth noting is that the alternate search is currently
a bit limited. It only supports searches involving types (classes,
interfaces, annotations, and enums). It doesn't currently have any
support for methods or fields.
Secondly, it can only search for and locate types within the current
source tree. Searching across the jdk source or other third party
source files without setting up an Eclipse or similar classpath, is
difficult at worst, and slow at best.
With that said, I've found that when I'm walking through a third party
source tree, my main focus is on finding referenced classes /
interfaces quickly and easily, and the eclim alternate searching does
just that.
Invoking the search is the same as the standard search mechanism. You
simply use the same :JavaSearch command as you normally would. The
only difference is that the alternate search doesn't support the -t
option and will notify you of such if supplied.
When invoked, the alternate search will perform the following:
- It will grab the full path of the current source file, strip off
the package and search from the resulting directory.
Ex. When editing a file
/usr/local/java/foo/src/org/foo/bar/Baz.java, the alternate search
will first search the directory /usr/local/java/foo/src.
- If no files are found in that directory, then it will proceed to
search Vim's 'path' option (:h 'path' for more info on this option).
As an example, I have my 'path' set to '/usr/local/java/java-src'
and in that directory is where I store all my third party source
distributions (hibernate, spring, axis, etc.).
- Once one or more files are found, the search will stop if the
requested search was for declarations. For all searches, eclim will
first try to find the declarations and if the user requested a
search for implementors, references, or all, then the eclim will
proceed to the next step.
- For non-declaration searches, if multiple declaring source files
are found, eclim will prompt you to narrow the results down to the
type you would like results for.
- Once eclim has narrowed the search down to the specific type to
proceed with, it will then attempt to narrow the search down to a
specific source distribution directory. To do this it locates the
relevant entry from the 'path' option, tacks on one more level of
the path from the resulting file, and commences its search from
there.
Ex. When searching for all implementors of MyType, if eclim finds a
file /usr/local/java/java-src/myproject/core/src/org/my/MyType.java
and a 'path' entry of /usr/local/java/java-src exists, then eclim
will deduce that that search must continue in the directory
/usr/local/java/java-src/myproject.
This may seem a bit complicated for a simple search, but in practice
it's actually quite simple, and as usual, I'm open to any and all
comments and suggestions.
Note: Alternate searching is bound to the performance of the file
system and as such, the response time on Windows can be
significantly slower than Linux. This is most noticable when
searching for 'implementors', 'references', and 'all'. The number
of and depth of the directories in your Vim 'path' option may also
impact performance.
Configuration
=============
Eclim Settings (vim-settings)
*org.eclim.java.search.sort*
- org.eclim.java.search.sort - Json formatted list of project
releative paths used to sort the search results.
For example, if your projects follow maven hierarchy and you want
the test references to be listed after the main code references,
then you can configure this setting like so:
>
org.eclim.java.search.sort=["src/main", "src/test"]
<
Vim Settings (vim-settings)
*g:EclimJavaSearchSingleResult*
- g:EclimJavaSearchSingleResult (Default: 'split') - Determines what
action to take when a only a single result is found.
Possible values include:
- 'split' - open the result in a new window via "split".
- 'edit' - open the result in the current window.
- 'tabnew' - open the result in a new tab.
This setting overrides the global default for all supported language
types which can be set using the g:EclimDefaultFileOpenAction
setting which accepts the same possible values.
- g:EclimQuickFixOpen (Default: 'botright copen') Specifies the
command used to open the quickfix window when multiple results are
found.
- g:EclimQuickFixHeight (Default: 10) - Sets the height, in lines,
of the quickfix window when eclim opens it to display search
results.
*g:EclimJavaSearchMapping*
- g:EclimJavaSearchMapping (Default: 1) - When set to 1, <enter>
will be mapped to the java search functionality for the various java
related xml files (spring, hibernate, web.xml, and
struts-config.xml).
vim:ft=eclimhelp

51
vim-plugins/bundle/eclim/doc/vim/java/types.txt Normal file
View file

@ -0,0 +1,51 @@
*vim-java-types.html*
Type Creation
*************
*:JavaNew*
Creating a new Class, Interface, etc.
=====================================
:JavaNew is a command that allows you to create new classes,
interfaces, enums, or annotations by specifying which of those you'd
like to create, followed by the fully qualified path of the new type.
The available types you can create include:
- class - a new class
- interface - a new interface
- abstract - a new abstract class
- enum - a new enum
- @interface - a new annotation
Here are some examples:
>
:JavaNew class org.test.MyNewClass
:JavaNew interface org.test.MyNewInterface
<
If you ommit the package name, the new type will be created in the
same package as the file you are currently editing:
>
:JavaNew class MyNewClass
<
Note: This command supports command completion of the available
types (class, interface, etc) as well as completion of existing
package names.
In the case where the source directory to create the type in is
ambiguous, you will be prompted to choose the source directory from a
list.
vim:ft=eclimhelp

233
vim-plugins/bundle/eclim/doc/vim/java/unittests.txt Normal file
View file

@ -0,0 +1,233 @@
*vim-java-unittests.html*
Unit Tests
**********
*:JUnit*
JUnit
=====
Executing tests.
----------------
Eclim's :JUnit command allows you to execute individual test or
individual methods from your tests.
If you'd like to run a particular test you can do so by supplying the
fully qualified class name of the test to run (you can use vim's tab
completion here to alleviate having to type the full name):
>
:JUnit org.test.MyTest
<
Another way is to simply run :JUnit with no arguments and let it
decide what to run based on the current context of the cursor:
- If you have a junit test file open and the cursor is not inside
one of the test methods, then all of the current file's test methods
will be executed.
- If the cursor is on or inside of a test method, then just that
method will be run.
- If you have a regular class open and run :JUnit, eclim will
attempt to locate the corresponding test and run it.
- If the cursor is on or inside of a method in a regular class,
eclim will attempt to locate the test and then locate the
corresponding test method for the current method in that test and
run just that test method.
If you'd like to run all tests for the current file, regardless of
whether the cursor is on a method or not, you can do so by running
:JUnit with the '%' argument:
>
:JUnit %
<
For cases where you'd like to run all your unit tests you can run
:JUnit with the '*' argument and eclim will locate all your test files
and run them:
>
:JUnit *
<
You can also pass in an ant compatible pattern
(http://ant.apache.org/manual/dirtasks.html#patterns) to match the
tests you'd like to run:
>
:JUnit **/tests/*Test
<
*:JUnitFindTest*
Find the test for the current source file.
------------------------------------------
When editing a java file, if you would like to open the corresponding
test, you can issue the command :JUnitFindTest. When the cursor is on
a method in your source file this command will also try to find the
corresponding test method within the test file.
If you run :JUnitFindTest from a test class, eclim will attempt to
find the corresponding class that is being tested.
*:JUnitResult*
Opening test results run from you build tool.
---------------------------------------------
If you are running your unit tests from a build tool like ant or
maven, then you most likely are writing those results to a directory
in your project. If so then you can set the
org.eclim.java.junit.output_dir setting to that location which then
allows you to use the command :JUnitResult to locate and opening the
result file for the currently open test or the test supplied as an
argument.
*:JUnitImpl*
Generating test method stubs.
-----------------------------
While editing junit files, eclim provides functionality to generate
test method stubs similar to the method override / impl (|:JavaImpl|)
functionality provided for non-test-case classes. The only difference
is that instead of :JavaImpl, you use :JUnitImpl to open the window of
possible methods to implement.
To determine what class the current test is for, eclim expects that
the standard naming convention for tests is followed, where the test
has the same fully qualified class name as the target class with a
'Test' suffix.
So for the test org.foo.bar.BazTest, the exepected class being tested
would be org.foo.bar.Baz.
Note: Eclim also supports tests with a 'Test' prefix instead of a
suffix and in the case of neither a 'Test' prefix or suffix, it will
search for a class of the same name in a different package should
you perhaps use a package convention for your tests rather than a
class name convention.
When invoking :JUnitImpl from within org.foo.bar.BazTest, eclim will
locate the class org.foo.bar.Baz and generate a list of methods to
test from it.
When you hit <enter> on the method to add, if that method belongs to a
type in the hierarchy for the class being tested, then the
corresponding test method stub will be inserted, otherwise a regular
overriding stub will be generated.
Configuration
-------------
Eclim Settings (vim-settings)
*org.eclim.java.junit.output_dir*
- org.eclim.java.junit.output_dir - Defines the project relative
location of the junit test results.
Ex.
>
org.eclim.java.junit.output_dir=build/test/results
<
*org.eclim.java.junit.jvmargs*
- org.eclim.java.junit.jvmargs - Json formatted list of strings to
supply as args to the jvm when forking to run unit tests.
Ex.
>
org.eclim.java.junit.jvmargs=["-Xmx512m"]
<
*org.eclim.java.junit.sysprops*
- org.eclim.java.junit.sysprops - Json formatted list of strings to
supply as system properties to the jvm when forking to run unit
tests.
Ex.
>
org.eclim.java.junit.sysprops=["file.encoding=UTF8", "foo.bar=baz"]
<
*org.eclim.java.junit.envvars*
- org.eclim.java.junit.envvars - Json formatted list of strings to
supply as environment variables to the jvm when forking to run unit
tests.
Ex.
>
org.eclim.java.junit.envvars=["FOO=bar"]
<
TestNG
======
Currently eclim's support for TestNG (http://testng.org/doc) is
limited to supporting Vim's :make in conjunction with ant to populate
vim's quickfix results with failed tests.
By default TestNG's output to the console is very terse. So in order
to support monitoring of failed tests via vim's error format, eclim
provides a custom TestNG listener which must be installed into your
build environment.
1. The first step is to place the eclim-testng.jar file in your
TestNG classpath you have configured for ant. You can find this
jar file in your $ECLIPSE_HOME/plugins/org.eclim.jdt_version/
directory.
2. The second step is to add the listener attribute to your testng
task which references the required eclim testng listener:
>
...
<testng ... listener="org.eclim.testng.TestNgListener">
...
<
See the testng ant task docs (http://testng.org/doc/ant.html) for
more information.
Once you have completed that setup, you should then be able to run
your ant target from vim and (as long as eclim is running) all failed
tests will be added to your vim quickfix results.
Ex. Assuming your ant task is named 'test':
>
:Ant test
<
vim:ft=eclimhelp

142
vim-plugins/bundle/eclim/doc/vim/java/validate.txt Normal file
View file

@ -0,0 +1,142 @@
*vim-java-validate.html*
*:Validate_java*
Java Validation / Correction
****************************
Validation
==========
When saving a java source file that resides in a project, eclim will
update that source file in Eclipse and will report any validation
errors found. Any errors will be placed in the current window's
location list (:help location-list) and the corresponding lines in the
source file will be marked via Vim's :sign functionality with '>>'
markers in the left margin.
Automatic validation of java source files can be disabled via the
g:EclimJavaValidate variable (described below). If you choose to
disable automatic validation, you can still use the :Validate command
to manually validate the current file.
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimJavaValidate*
- g:EclimJavaValidate (Default: 1) - If set to 0, disables source
code validation.
Note: When enabled, syntastic
(https://github.com/scrooloose/syntastic) is disabled so that
eclim and syntastic don't step on each other. If you'd like to use
syntastic over eclim for validation, then simply disable eclim's
validation.If you'd like to disable eclim's source code validation
for all languages, eclim provides a global variable for that as
well:>
let g:EclimFileTypeValidate = 0
<
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
Eclim settings
*org.eclipse.jdt.core.compiler.source*
- org.eclipse.jdt.core.compiler.source - Determines the target java
vm version (1.2, 1.3, 1.4, 1.5).
*:JavaCorrect*
Code Correction
===============
Code correction in eclim is equivalent to the quick fix functionality
of Eclipse. When you save a java source file, eclim validates () the
file and notes which lines contain errors. To have eclim suggest
possible corrections for an error, you simply place the cursor on the
error line and issue :JavaCorrect.
The result will be a small window opened at the bottom of Vim where
any correction proposals will be noted. To apply a suggested change,
simply move the cursor to the line describing the modification and hit
<enter>. Upon doing so, the change will be applied to the source file.
Example output of :JavaCorrect.
>
The serializable class Foo does not declare a static final serialVersionUID field of type long
0.1227: Add @SuppressWarnings 'serial' to 'Foo'
...
@SuppressWarnings("serial")
public class Foo
implements Serializable
...
<
To apply the above change you would hit <enter> on the line:
>
0.1227: Add @SuppressWarnings 'serial' to 'Foo'
<
Note: Java code corrections are handled just like a refactoring
(vim-java-refactor) so the RefactorUndo (|:RefactorUndo|) and
RefactorRedo (|:RefactorRedo|) commands can be used to undo/redo
corrections that can't be handled by vim's undo (like file moves).
*:Checkstyle*
Checkstyle
==========
When editing a java source file, eclim provides the command
:Checkstyle which will invoke checkstyle
(http://checkstyle.sourceforge.net/) on the current file.
Additionally, you can configure eclim to execute checkstyle
automatically when you save a java source file by setting the eclim
project settings org.eclim.java.checkstyle.onvalidate to true.
Please note that both methods of invoking checkstyle require that you
first configure the location of your checkstyle config file using the
eclim setting org.eclim.java.checkstyle.config, described in the
configuration section below.
Configuration
-------------
Eclim Settings (vim-settings)
*org.eclim.java.checkstyle.config*
- org.eclim.java.checkstyle.config - Defines the location (project
relative or absolute) or your checkstyle config file.
*org.eclim.java.checkstyle.properties*
- org.eclim.java.checkstyle.properties - Defines the location
(project relative or absolute) or your checkstyle properties file.
*org.eclim.java.checkstyle.onvalidate*
- org.eclim.java.checkstyle.onvalidate - When set to true,
checkstyle will be run on the file along with the regular java
validation upon writing the file.
vim:ft=eclimhelp

39
vim-plugins/bundle/eclim/doc/vim/java/webxml.txt Normal file
View file

@ -0,0 +1,39 @@
*vim-java-webxml.html*
WEB-INF/web.xml
***************
Validation
==========
When editing a web.xml file eclim will default to validating the file
when it is written. Any errors will be added to the current window's
location list (:help location-list) and their corresponding line
number noted via Vim's sign functionality.
Eclim also combines the above validation with xml validation
(vim-xml-index#xml-validation) to validate that the file is well
formed.
If you do not want your web.xml files validated automatically when
saved, you can set the |g:EclimWebXmlValidate| variable described in
the configuration section below.
*:Validate_webxml*
Whether or not auto validation has been enabled, eclim also exposes
the command :Validate to manually execute the validation of the file.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimWebXmlValidate*
- g:EclimWebXmlValidate (Default: 1) - If set to 0, disables
validation when saving the file.
vim:ft=eclimhelp