I am working under Mac OS X 10.7. I got javacomplete working with the help of pathogen, but it only completes JDK classes, not the classes I've created. When trying to omni-complete one of my objects I'm getting 'Pattern not found'. Is this really limited to JDK classes? If not, can anybody describe their config.
BTW, I've tried created ctags but it didn't work with javacomplete either. However, ctrl-x ctrl-] works fine with ctags created.
You need to set up the class path for your sources.
From the javacomplete documentation:
3. Set classpath using the following function: >
javacomplete#AddClassPath('jarfile_or_classes_path')
javacomplete#DelClassPath('jarfile_or_classes_path')
javacomplete#SetClassPath('semicolon_separated_string')
Another two variables will be used if they are existing:
|g:java_classpath| global classpath
|b:classpath| associated with current buffer
I have added the following to my .vimrc to auto-complete android projects:
if filereadable('AndroidManifest.xml')
call javacomplete#SetClassPath('/home/tidbeck/android/sdk/android-sdk-linux_x86/platforms/android-17/android.jar:libs/android-support-v4.jar:bin/classes')
call javacomplete#SetSourcePath('src')
endif
Two things that I noticed:
javacomplete#AddClassPath does not support jar files even though the docs say so
I had to remove my tags file to get completion to working
I've used javacomplete plugin along with supertab and i found that the easiet way to enable method completion is by using another plugin called easytags.vim that automatically creates tags as you compile your classes. From memory it did provide user defined Class and method completion.
After installing the vim plugin you have to add these lines into .vimrc:
" Only do this part when compiled with support for autocommands.
if has("autocmd")
autocmd Filetype java setlocal omnifunc=javacomplete#Complete
endif
I am, too, was unable to get it working with an existing tags file (created by ctags). As mentioned, one workaround is to unset the vim option tags inside .vimrc. But this was not an option for me.
I just manipulated javacomplete.vim to "ignore" the tags file.
Patch follows:
--- autoload/javacomplete.vim 2011-01-30 21:33:46.000000000 +0100
+++ /home/kndl/.vim/autoload/javacomplete.vim 2015-02-12 20:46:48.227465321 +0100
## -2510,7 +2510,8 ##
fu! s:GetClassInfoFromSource(class, filename)
let ci = {}
if len(tagfiles()) > 0
- let ci = s:DoGetClassInfoFromTags(a:class)
+ " kndl: Deactivate ctags feature as this does not work. It seems that I am unable to build an accepted tags file.
+ "let ci = s:DoGetClassInfoFromTags(a:class)
endif
if empty(ci)
Related
Motivation:
In our code we have a few places where some methods are run by their name. There are some big if-else-if blocks with each function name and call of the corresponding method (I use the term function to describe just names, for example function X01 might correspond to method SomeClass.functionX01). I've been looking into ways to improve that
Goal:
Write just methods that are annotated with some custom annotation, removing the need to update or even include if-else-if blocks in order to run specific function. Have access to any generated code if any code is generated.
What I did:
I've created first prove of concept using runtime annotations and it proved successful, but slower then if-else-if. Next attempt was with source annotation
I've followed this link for an example, however it did not seam to run in IntelliJ. What I wanted is to have - in this case PersonBuilder class generated, instead there was none. In some cases an error was raised Error:java: Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: Provider BuilderProcessor not found
After some Googling and failing to find anything I've turned to book (Core Java, Volume II - Advanced Features - 9th Edition, Polish translation) and there was reccomended to run the following commands:
javac [AbstractProcessor implementation]
javac -processor [Compiled Processor] [other source files to compile]
This worked, however is unsatisfactory as it needs to happen inside IDE (NetBeans and IntelliJ to be specific) automatically during build. Code does not need to be generated on the fly, but programmer must have access to it after build (as in - be able to call methods of generated classes)
Question:
How to have and use generated code used in NetBeans and IntelliJ without the need of using external tools? Is it possible, or using reflection, runtime annotations or external tools is the only way?
Additional info (just in case):
Language level: Java 1.8
JVM versions: 12 and 13
IDEs: NetBeans and IntelliJ
We already tried the approaches as listed below:
https://github.com/oliverlockwood/jenkinsfile-idea-plugin
https://st-g.de/2016/08/jenkins-pipeline-autocompletion-in-intellij
After having searched the web for many hours on multiple days, we still haven't found a helpful resource on this matter. Thus, it appears to make sense to ask a new question here.
We are developing our Java projects in IntelliJ idea and want to integrate our builds with Jenkins. When we create a Jenkinsfile in Idea, we do not get syntax highlighting or auto completion. Since we are new to Jenkins, those features would be really useful to us. How can we make Idea be more supportive with Jenkinsfiles?
If there is no way to get syntax highlighting and auto completion for a Jenkinsfile in IntelliJ IDEA, what other editors would be helpful?
Please note:
we are working with Java projects, not Groovy projects.
We've already tried the plugin https://github.com/oliverlockwood/jenkinsfile-idea-plugin. When the plugin is activated, the Jenkinsfile is recognized as such, but instead of syntax highlighting we get an error message, please see below.
pipeline {
agent { docker 'maven:3.3.3' }
stages {
stage('build') {
steps {
sh 'echo Hello, World!'
}
}
}
}
IntelliJ IDEA highlights the p of pipeline as error. The error message reads:
JenkinsTokenType.COMMENT, JenkinsTokenType.CRLF or
JenkinsTokenType.STEP_KEY expected, got 'p'
Thanks for any help!
If you want IDEA to recognize a Jenkinsfile as a Groovy file, then you can add the String "Jenkinsfile" as a valid file name pattern (normally contains file endings) for Groovy files. This is supported "out of the box" without requiring any additional Plugin (except the "Groovy" Plugin, but that is already part of IDEA).
To do that go to the settings menu, open the "Editor" item and then "File Types". Now select "Groovy" in the upper list and add "Jenkinsfile". You can also use a regex like "Jenkinsfile*" if you want to be more flexible regarding an optional file ending for the Jenkinsfile.
The setting should now look like this:
Your example now looks like this in IDEA (with the Dracula theme):
So IDEA now provides syntax highlighting and auto completion as far as I can tell. It suggests existing function/method names while writing, but I'm not a Groovy developer, thus I can't tell if some suggestions are missing.
At long last we found a solution that works for us and provides syntax highlighting and code completion for the Jenkinsfile present in an otherwise normal Java project in Idea.
The solution is taken from here, here (and from additional personal experiments / research)
Download the Groovy SDK (if you did not do so already) from the Groovy Page and configure it on your Java project. For help on this see here
Download the pipeline GDSL file from your Jenkins instance which should be available under a link like https://yourJenkinsInstance.tld/pipeline-syntax/gdsl, and add it to the classpath of your Java project. E.g. by creating a new folder src/main/jenkins, putting the pipeline gdsl file there and marking the folder as source root in IntelliJ Idea
Add "Jenkinsfile" as a valid file name pattern for groovy files as described here
To avoid the error message 'node' cannot be applied to '(groovy.lang.Closure<java.lang.Object>), you can add this line at the top of your Jenkinsfile:
// noinspection GroovyAssignabilityCheck
If you add
#!groovy​
header to your jenkinsfile then you should get groovy syntax highlighting in IDE.
Another option is to use a shabang on top of the Jenkinsfile like this #!/usr/bin/env groovy. Also you can try out gdsl: https://st-g.de/2016/08/jenkins-pipeline-autocompletion-in-intellij
but so far it doesn't support declarative pipelines: https://issues.jenkins-ci.org/browse/JENKINS-40127
Looking at the source code, it looks like COMMENTS are not defined (they are commented out in the code)
The STEP_KEY is defined as: STEP_NAME="sh" | "parallel"
I'm not sure the plugin does much more and it hasn't been updated in 2 years.
go to the settings menu, open the "Editor"--> "File Types". Now select "Groovy" in the upper list and add ".Jenkinsfile". You can also use a regex like ".Jenkinsfile" if you want to be more flexible regarding an optional file ending for the Jenkinsfile.
Jenkinsfile is a groovy like script, but normally IntelliJ map it to TextMate editor.
To do that go to the settings menu, open the "Editor" item and then "File Types". Now select "TextMate" in the upper list and add "Jenkinsfile". You can also use a regex like "Jenkinsfile*" if you want to be more flexible regarding an optional file ending for the Jenkinsfile.
Use sh like this and the error should go away (worked for me)...
steps {
sh """
echo 'Hello, World!'
"""
}
I'm trying to use a java library in RIDE. I found a good tutorial( https://blog.codecentric.de/en/2012/06/robot-framework-tutorial-writing-keyword-libraries-in-java/)
I follow it, but when the time comes to import and use the java library ( Database Library)in RIDE. It fails. When I look the page with my different imports, the java library is written in red and not in black as the others.
And when I try to run with Jybot, I have the well-known message :
[ ERROR ] Error in file 'C:\Users\XXXXXX\Documents\Robot_Test\implementation\DB_Test\Example.html': Importing test library 'org.robot.database.keywords.DatabaseLibrary' failed: ImportError: No module named robot
I follow every line of the tutorial, even the with the set CLASSPATH.
Any idea ? ( I know that this library exist in Python, but I want to write my own java libraries ^^)
Thanks
This worked for me using:
Jython 2.7b4
Robotframework 2.8.7
Ride 1.3
Create Lib and compile it (you do not need to jar it)
Directory structure is
run_ride.sh
libs/DemoLib.class
tests/DemoLibTest.txt
Excerpt from tests/DemoLibTest.txt:
* Settings
Library ../libs/DemoLib.class
* Test Cases
DemoLibTest
Print Demo
Start Ride, switch to tab "Run", choose Execution Profile: jybot, press Start, output is:
Starting test: tests.DemoLibTest.DemoLibTest
20150304 19:13:20.321 : INFO : ---------- Demo ---------------
To avoid confusion put this line
echo $CLASSPATH
in your Ride startup script in order to ensure that your library is really imported. By the way, in my Ride the import is also marked red. Sometimes restarting Ride might help. But the colour does not mean anything, if your settings are correct.
I am using Maven, with the one-jar pluggin, but when I run the one jar executable, I'm greeted with a wall of warnings, this is unacceptable for use
I've looked at every available resource on one-jar and see no instruction on how to keep the jar for spewing out tons of warnings when run, has anyone solved this?
JarClassLoader: Warning: META-INF/LICENSE.txt in lib/commons-io-1.4.jar is hidden by lib/commons-collections-3.2.1.jar (with different bytecode)
JarClassLoader: Warning: META-INF/NOTICE.txt in lib/commons-io-1.4.jar is hidden by lib/commons-collections-3.2.1.jar (with different bytecode)
JarClassLoader: Warning: META-INF/LICENSE.txt in lib/commons-lang-2.4.jar is hidden by lib/commons-collections-3.2.1.jar (with different bytecode)
JarClassLoader: Warning: META-INF/NOTICE.txt in lib/commons-lang-2.4.jar is hidden by lib/commons-collections-3.2.1.jar (with different bytecode)
I found that if you create a one-jar.properties file and put it in the root of your runtime classpath (ie, where your project .class files end up), it will be read by the one-jar Boot class. An entry in this properties file such as:
one-jar.silent=true
will suppress the one-jar log messages altogether.
Other values that the Boot class looks for are one-jar.info and one-jar.verbose.
The default level is INFO. As Pascal Thivent indicated above, you can also set a System property via the command line with the -D parameter of the java command, but if you do not want to have to stipulate or remember this, the properties file approach works great.
It seems that these messages are printed when running in "verbose" mode. What I don't get is that the verbose mode doesn't seem to be activated by default.
Anyway, could you try to set the one-jar.verbose system property to false when running your one-jar:
java -Done-jar.verbose=false -jar <one-jar.jar>
Regarding the latest-and-greatest One-Jar v0.97: The problem is there. The 'one-jar.properties' file actually needs to be put into the root of the final jar. It will, of course, have one line that reads, one-jar.silent=true. This can be done in Ant by setting something like <fileset dir="${build.dir}" includes="**/*.properties" /> inside the <one-jar ...> task.
It can also, just as easily, be placed into the command line using the java -Done-jar.silent=true -jar foo-jar-made-by-one-jar.jar command.
Nevertheless, it will still report a single line that it's loading properties from the One-Jar internal Boot class before going quiet. There is no way to get around this without changing source code starting at line 317 in Boot.java where the method initializeProperties logs the loading/merging operations. See Bug ID 3609329 at SourceForge in the One-Jar bug tracker where I provided the quick fix.
Summary: By adding the one-jar.properties file all but one line of extraneous logging is removed. This should help Maven users find a workaround.
This is much better in the new version of the Maven one-jar plugin.
Add the plugin repository:
<pluginRepository>
<id>one-jar</id>
<url>http://onejar-maven-plugin.googlecode.com/svn/mavenrepo</url>
</pluginRepository>
and use version 1.4.4 in the plugin definition.
I found I needed to use version 1.4.5 (1.4.4 did not work) and then the suggestion to place a one-jar.properties file at the root of my jar file with a single line reading one-jar.silent=true worked for me.
I upgraded fromr 1.4.3 to 1.4.4 as someone suggested before and that made the deal
There's two places to get the one-jar plugin from.
https://github.com/jolira/onejar-maven-plugin
http://code.google.com/p/onejar-maven-plugin/
The 1st one claims to be just a copy of the 2nd one that's served from Maven's main repository. I was encouraged to use this one as it doesn't require specifiying an additional plugin repository that the 2nd one requires. However, when I switched to use the 2nd one (the official one), this problem went away for me.
Note - passing -Done-jar.verbose=false worked for me but not when set in file one-jar.properties as someone stated above.
I submitted a patch for this quite some time ago that merely makes the default behavior silent.
public static final int LOGLEVEL_VERBOSE = 5;
// Loglevel for all loggers.
- private static int loglevel = LOGLEVEL_INFO;
+ private static int loglevel = LOGLEVEL_NONE;
private final String prefix;
AFAIK, it never got applied. Recently I fixed another issue, so I put my fixes out here:
https://github.com/nsoft/uno-jar
Please Re-read the "as is, no warranty" part of the license several times :)
There is no way to do this without modifying the source code
Looks like Jetty team wanted to do some spring cleaning between versions 6 and 7, and it looks as if one useful system property, "jetty.lib" either does not exist, does not work, or just has changed in an unspecified way so as to make my jetty 6 set up work easily with Jetty 7.
I tried searching through Jetty 7 docs, but about the only reference I saw was that "some commonly used properties (such as "jetty.home") still work as they used to".
So, what am I missing? I really would want to avoid messing with things within Jetty distribution dirs (otherwise I could -- and maybe I have to? -- just use JETTY_BASE/lib/ext), and that's what "jetty.lib" was useful for.
Ok looks like answer was hidden within "start.config" (bundled in start.jar), which defines fundamental path settings. Specifically, among first lines, we have:
# add a property defined classpath
${path}.path property path
# add a property defined library directory
${lib}/** exists ${lib}
so one might think property to use would be:
java -jar start.jar -Dlib=mydir/lib
but this is not the case: trick being that here curlies mean that it has to be a "property" (not "property or system property"). And hence what is really needed is:
java -jar start.jar lib=mydir/lib
or at least that seems to work.
As an added bonus, it looks you could also override "start.config" to use by doing
java -jar start.jar -DSTART=my-start.config ...
which would give full power of redefining method used for setting paths altogether.
I hope others find this useful.
UPDATE: This Jetty doc explains most of above even better...