Develop Reference

When specifying -javaagent, is it possible to have a jarpath containing = (equal) in it?

Question
Is it possible to use a jarpath containing an equal sign when specifying an agentlib ? For example, using some kind of escaping ?
Note: the syntax to specify the java agent is -javaagent:jarpath[=options] (see the official documentation).
Context
I have a Continuous Integration setup where paths contains an = (equal) sign.
And I have problems running the maven surefire plugin which fails at startup because the agent jar is not found.
I dig a bit and found that
And our command line looks like /<path-to-jre>/bin/java -javaagent:/<path-to-jenkins-workspace>/myProject=myJobName/.repository/org/jacoco/org.jacoco.agent/0.7.9/org.jacoco.agent-0.7.9-runtime.jar=destfile=/<path-to-jenkins-workspace>/myProject=myJobName/target/jacoco.exec,append=true <other arguments to java dropped>.
I made this command work by renaming the project to myProject+myJobName, thus I'm sure that the problem lies with the use of equal.
Note that the above command line is directly generated by maven-surefire-plugin, thus I don't have many options to alter it.

According to Sylvain's comment, this is not possible with OpenJDK 9.
This is probably the same with earlier JDK and the one from Oracle

how to complete user defined class methods using javacomplete

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)

one-jar remove verbose warning information on application load

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

Jetty 6 to Jetty 7 upgrade: what happened to system property "jetty.lib"? (-Djetty.lib=my/lib/dir)

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...

Anyone heard about a standard property deployment.name?

I've just fought for a whole day with a strange maven problem:
I had a custom property called "deployment.name" that was never to resolved to what I configured for it, but rather the maven filtering mechanism always replaced it by the project's name.
I tried the goal "help:expressions" to find out whether this is a preconfigured property, but that goal only throws exceptions in m2eclipse. Google does not seem to know a pre-configured
property by that name.
The strangest bit: deployment.somethingelse works perfectly fine, so I ended up replacing ".name" with ".depname", then it works ;.)

The Maven Super POM defines the common configuration for all Maven projects. The values in that are accessible as properties (and , so that is where most of the properties you generally use come from (e.g. ${project.build.directory}), these are the pretty much the same as the output of help:expressions.
There is no deployment section in the super POM. The only thing I can think of is that the property is being set somewhere else, e.g. in a profile, or overridden by a plugin (though that seems unlikely). You could try running mvn help:effective-pom to see if the property is being set by a profile.
Are you able to post your POM? that might help diagnose it.

... I just ran help:effective-pom, and there is no trace of "deployment.name" in the output.
I can see all the other properties that I defined though (e.g. "deployment.depname").
Maybe "name" is a reserved attribute of some sort? Maybe debugging into m2eclipse will shed light on this riddle.