Develop Reference

Eclipse: Setting an environment variable that references a folder contained in a plugin

I have some Java code that wraps an existing native application and performs the following:
Takes some input from the user
Executes a native application providing as parameters the input taken in step 1
Performs some more operations on the output files produced in step 2
The native application in step 2 requires some dynamic libraries. So, under Run Configurations -> Environment I have set the following variables to reference the libraries.
DYLD_LIBRARY_PATH = ${project_loc}/path/to/libs
DYLD_FALLBACK_LIBRARY_PATH = ${project_loc}/path/to/libs
And so far it all works. Now I have packaged my code and the existing native application as an Eclipse plugin. Whenever I try to run the code inside the plugin I get the following error:
dyld: Library not loaded: libsrcml.dylib
Referenced from: workspace/Project/src/nativeApp
Reason: image not found
To my understanding, this happens because the environment variables I had set previously reference {$project_loc}, which is the location where my Eclipse project was stored. Now, my code is no longer contained in that project, but it is contained inside a plugin, so the path for the variables no longer works. Question is, how can I set a path that references a folder inside my plugin? Alternatively, is it possible to, somehow, load those variables dynamically inside my Java code?

The path variables are used to specify a fixed location in the file system.
To identify a resource in a plugin, I would use its URL
Case 1: Platform.getBundle("").getEntry("")
Bundle bundle = Platform.getBundle("your.bundle.id");
URL url = bundle.getEntry("yourDir/yourFile.txt");
File f = new File(FileLocator.resolve(url).toURI());
Case 2 : Platform URL to your resource:
url = new URL("platform:/plugin/your.bundle.id/yourDir/yourFile.txt");
File f = new File(FileLocator.resolve(url).toURI());
Thanks to Vogella for this tip.
However, for libraries in your plug-in it is a little bit different, as System.loadLibrary("libname") must be able to resolve your lib.
If you ship and use native libraries in your plug-in, please package your plugin as a directory, and not as a compressed jar file.
So edit your plug-in's MANIFEST.MF and set your Eclipse-BundleShape: dir
Eclipse-BundleShape: dir
Then, your plug-in will be packaged as a folder, and then it is your responsibility to make your Native libraries interacting. Usually this depends on how the native libraries are linking each other, and on how your Java-to-native framework is setting the search paths.
My simple solution, is putting all the native libraries to the root folder of the Eclipse executable, which is the Java execution directory, so that I can get that path using the "user.dir" environment variable as follows:
System.getProperty("user.dir");
Then, when all the natives are in the same folder, they can reference each other without problems.
Please, also check these resources:
this StackOverflow answer
this eclipse forum answer

What exactly is a class path in java?

I wrote a program that works on my laptop perfectly, but I really want it to work on a server that I have. Using NetBeans, I've clean and built the project. I copied the contents of the folder dist on my server but I cannot seem to get to work by using command
java -jar nameOfFile.jar
I get the error
java.lang.NoClassDefFoundError: org/....
I have been doing some reading and from what I gather is that I need to pretty much specify where the libraries that I've used are located. Well they are located in a subfolder called lib.
Question:
So what would I need to do in order to be able to run my jar?

CLASSPATH is an environment variable that helps us to educate the Java Virtual Machine from where it will start searching for .class files.
We should store the root of the package hierarchies in the CLASSPATH environment variables.
In case of adding or using jar libraries in our project, we should put the location of the jar file in the CLASSPATH environment variable.
Example: If we are using jdbc mysql jar file in our java project, We have to update the location of the mysql jar file in the CLASSPATH environment variable. if our mysql.jar is in c:\driver\mysql.jar then
We can set the classpath through DOS in Windows
set CLASSPATH=%CLASSPATH%;c:\driver\mysql.jar
In Linux we can do
export CLASSPATH=$CLASSPATH:[path of the jar]
Hope it helps!

Try that:
java -classpath "$CLASSPATH:nameOfFile.jar:lib/*" path.to.your.MainClass
What this does is setting the classpath to the value of $CLASSPATH, plus nameOfFile.jar, plus all the .jar files in lib/.

Classpath
A compiler(e.g. javac) creates from .java - .class files and JVM uses these .class files.
classpath - local codebase[About] - points on the root of source. classpath + import_path = full path
For example for MacOS
//full path
/Users/Application.jar/my/package/MainClass
//classpath
/Users/Application.jar
//import_path
my.package.MainClass
Android classpath
ANDROID_HOME/platforms/android-<version>/android.jar
//e.g
/Users/alex/Library/Android/sdk/platforms/android-23/android.jar

When you use a META-INF/MANIFEST.MF file to specify the Main-Class dependencies must be specified in the manifest too.
The -jar switch ignores all other classpath information - see the tools docs for more.

You need to set class path using
The below works in bash .
This is temporary
set CLASSPATH=$CLASSPATH=[put the path here for lib]
If you want it permanent then you can add above lines in ~/.bashrc file
export CLASSPATH=$CLASSPATH:[put the path here for lib]:.

You have 2 questions, one is the "title question" and another is the "foot note question" after elaborating your problem.
Read this documentation bellow to get a better understanding of CLASSPATH.
https://docs.oracle.com/javase/tutorial/essential/environment/index.html
https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html
This is fast and straight forward for what you need.
For your first question, this will do:
The documentation recommends us to set a classpath for every application we are running at the moment using (use in the command-line):
java -classpath C:\yourDirectoryPath myApp
For your second question, look this exercise in the java documentation. It seems to be the same problem:
https://docs.oracle.com/javase/tutorial/essential/environment/QandE/answers.html
Answers to Questions and Exercises: The Platform Environment
Question 1.A programmer installs a new library contained in a .jar file. In order to access the library from his code, he sets the CLASSPATH environment variable to point to the new .jar file. Now he finds that he gets an error message when he tries to launch simple applications:
java Hello
Exception in thread "main" java.lang.NoClassDefFoundError: Hello
In this case, the Hello class is compiled into a .class file in the current directory — yet the java command can't seem to find it. What's going wrong?
Answer 1. A class is only found if it appears in the class path. By default, the class path consists of the current directory. If the CLASSPATH environment variable is set, and doesn't include the current directory, the launcher can no longer find classes in the current directory. The solution is to change the CLASSPATH variable to include the current directory. For example, if the CLASSPATH value is c:\java\newLibrary.jar (Windows) or /home/me/newLibrary.jar (UNIX or Linux) it needs to be changed to .;c:\java\newLibrary.jar or .:/home/me/newLibrary.jar."

The class folder is not associated to any output library entry

My Eclipse plugin project which holds libraries used by other OSGi plugins gives me the following warning:
The class folder 'lib/' is not associated to any output library entry.
What does it mean? Can I safely ignore it?
The whole feature consisting from 20 plugins works well, but I do not like to have any warnings in my code.
My build.properties file is:
source.. = src/
output.. = bin/
bin.includes = META-INF/,\
bin/,\
lib/,\
.
The search on google gave me this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=297483, but I'm still not sure how to fix this warning.

I found this hint to be helpfull (first google hit, as of 03-SEP-2013)
http://dev.eclipse.org/mhonarc/lists/pde-dev/msg01822.html
I removed META-INF from my bundle build path, cleaned (rebuilt) the project and the warning disappeared.

About the build.properties:
META-INF/ should be included in the bin.includes because actually this folder includes all the information associated to the classpath and runtime information. If not, another warning appears.
Icons must be added as well in the bin.includes.
Actually, we should try to avoid the addition of icons in the runtime information:
Statically declared plug-in icons are not meant to be in the runtime JAR >because Eclipse wants to load plug-ins lazily. In other words, during >loading of the platform, the platform loader reads only the plugin.xml >file and will use the icons that are declared there.
Taken from: https://wiki.eclipse.org/FAQ_Can_I_add_icons_declared_by_my_plugin.xml_in_the_runtime_JAR%3F
Example of one of my plugins:
Figure 1. Adding information in the bin.includes property
The reason is simple. Think about we want to deploy our plugin somewhere else. Then, we need to maintain a track about all the information that needs our plugin to be executed.
About the MANIFEST.MF:
There is another trick to organize the information that appears in the MANIFEST.MF besides the information that appears in the build.properties:
PDE provides an Organize Manifests wizard to help ensure that the >information in your Manifest is up to date. The wizard is available >through the Plug-in Tools menu after right clicking on a plug-in project's MANIFEST.MF or plugin.xml files.
Taken from: http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Fpde_actions%2Forganize_manifests.htm
Example of one of my plugins:
Figure 2. Organizing MANIFEST.MF

I think your issue is that in your MANIFEST.MF the section Bundle-ClassPath does not include a listing of the libraries. This means OSGi will not know if these classes are meant to be on the internal classpath. You will have to provide that information.
If you export everything in lib, every single one has to be listed in the MANIFEST.MF and the wildcard lib/ is fine for the PDE builder.
If you only want some in lib/ then you need to list those only, and the builder will either need an explicit list, or an exclude clause for the ones that you do not want.
If you are just using the libraries internally, but do not want to export them, then the settings for the exported packages are used.
I am unsure what to do in the case where you are packing up a jar file but actually do not want it on the classpath. I am guessing that a source.exclude with the name of the library might help. This is a really unusual corner case.
Bundle-ClassPath: lib/amf-aml_2.12-4.1.19.jar,
lib/amf-core_2.12-4.1.20.jar,
lib/amf-validation_2.12-4.0.3.jar,
lib/amf-webapi_2.12-4.0.3.jar,
lib/antlr4-runtime-4.5.3.jar,
lib/collection-0.7.jar,
lib/commons-beanutils-1.9.3.jar,
lib/commons-cli-1.4.jar,
lib/commons-codec-1.11.jar,
lib/commons-collections-3.2.2.jar,
lib/commons-compress-1.19.jar,
lib/commons-csv-1.5.jar,
lib/commons-digester-1.8.1.jar,
lib/commons-io-2.6.jar,
lib/commons-lang3-3.4.jar,
lib/commons-logging-1.2.jar,
lib/commons-validator-1.6.jar,
lib/handy-uri-templates-2.1.6.jar,
lib/httpclient-4.5.5.jar,
lib/httpclient-cache-4.5.5.jar,
lib/httpcore-4.4.9.jar,
lib/jackson-annotations-2.9.0.jar,
lib/jackson-core-2.9.8.jar,
lib/jackson-databind-2.9.8.jar,
lib/jcl-over-slf4j-1.7.26.jar,
lib/jena-arq-3.11.0.jar,
lib/jena-base-3.11.0.jar,
lib/jena-core-3.11.0.jar,
lib/jena-iri-3.11.0.jar,
lib/jena-shaded-guava-3.11.0.jar,
lib/joda-time-2.9.4.jar,
lib/json-20180130.jar,
lib/json4s-ast_2.12-3.5.4.jar,
lib/json4s-core_2.12-3.5.4.jar,
lib/json4s-native_2.12-3.5.4.jar,
lib/json4s-scalap_2.12-3.5.4.jar,
lib/jsonld-java-0.12.3.jar,
lib/libthrift-0.12.0.jar,
lib/org.everit.json.schema-1.9.2.jar,
lib/paranamer-2.8.jar,
lib/re2j-1.1.jar,
lib/scala-common_2.12-0.5.64.jar,
lib/scalactic_2.12-3.0.5.jar,
lib/scala-java8-compat_2.12-0.8.0.jar,
lib/scalajs-stubs_2.12-0.6.29.jar,
lib/scala-library-2.12.6.jar,
lib/scala-reflect-2.12.8.jar,
lib/scalatest_2.12-3.0.5.jar,
lib/scala-xml_2.12-1.0.6.jar,
lib/scopt_2.12-3.7.0.jar,
lib/shacl-1.3.0.jar,
lib/slf4j-api-1.7.26.jar,
lib/slf4j-simple-1.7.12.jar,
lib/syaml_2.12-0.7.270.jar,
lib/webapi-parser-0.5.0.jar,
lib/webapi-parser-0.5.0-javadoc.jar,
lib/webapi-parser-0.5.0-sources.jar,
.

How to get the path to the executable when using launch4j?

I'm using launch4j to wrap an executable jar file in my Windows application, but I need to pass references to some of its libraries in through the JVM arguments. The libraries in question reside in the application install directory, and are always located in the same place, relative to the executable.
I'd like to tell launch4j to use executable-relative paths in the JVM options. I know this information is available at the Windows batch script level, but how do you configure launch4j to fetch it?
Edit for clarification: I'm looking specifically for how to make the paths relative to the binary itself, not how to make them relative to the current working directory. The two aren't necessarily the same.

You might add to your launch4j configuration
...
<jre>
...
<opt>-Djna.library.path="%EXEDIR%\\path\\to\\lib"</opt>
<opt>-Djava.library.path="%EXEDIR%\\path\\to\\lib"</opt>
...
</jre>
...
If you need more then a you might seperate several paths by a semikolon as usual.
< opt> Optional, accepts everything you would normally pass to
java/javaw launcher: assertion options, system properties and X
options. Here you can map environment and special variables EXEDIR
(exe's runtime directory), EXEFILE (exe's runtime full file path) to
system properties. All variable references must be surrounded with
percentage signs and quoted.
Source: http://launch4j.sourceforge.net/docs.html

Set -Djna.library.path=<relative path of native libraries> (if using JNA) and -Djava.library.path=<relative path of native libraries>.
Alternatively, this can be done in Java code as: System.setProperty("jna.library.path","<relative path of native libraries>") and System.setProperty("java.library.path","<relative path of native libraries>"). You can append as many paths to refer to. In Windows, use ; to separate the paths.
This setup only has its effect on the JVM runtime of that Java application (not globally like LD_LIBRARY_PATH in Linux.)
Or, you can put this in Launch4J JVM options list under JRE tab. This is what I do in my projects.

One of the options in configuration is to allow a change directory chdir to the executables directory. This will set user.dir to same directory as exe, which you could use to find other application paths.
<chdir>
Optional. Change current directory to an arbitrary path relative to the executable. If you omit this property or leave it blank it will have no effect.
Setting it to . will change the current dir to the same directory as the executable. .. will change it to the parent directory, and so on.
<chdir>.</chdir>
<chdir>../somedir</chdir>
The code which find the actual path to executable will be dependent on OS (readlink, GetModuleFileName etc). Make sure you really test on target OSes..

If I understand your question correct, you have a launch4j executable and a native library within your installation directory:
/launch.exe
/bin/lib.dll
/lib/app.jar
Now you want to start you app.jar with the generated launcher (launch.exe). You app loads the lib.dll.
You can embed a file into your app.jar (marker.txt). Now you can use the ClassLoader
http://docs.oracle.com/javase/6/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)
getResource("marker.txt);
This will give you something like:
file://c://installdir/lib/app.jar!marker.txt
This String can be parsed. But in fact, I think there should be a better solution for this problem.

You can simply include the directory (e.g. ..\lib) where the libraries are located in the classpath tab in Launch4j. At least that worked for me.

Building with ant : dynamic build options?

With multiple developers working on the same Tomcat application, I'd like to tell the application to install to a different path, based on the current user and revision control client/view.
So, if Bob is building, the app should be installed in Bob's test environment, maybe /bob1 or something like that. Bob might have several revision control clients/views/workspaces he works with so he could have /bob1, /bob2, /bob3, etc.
The install location is specified in the build.properties file. Is there a way to avoid checking that file out and changing it for each specific user and revision control view?
Can "ant install" take arguments or be configured to consider environment variables for the install target?

I typically use a variation on the default properties answer already given:
<property file="local.properties" />
<property file="default.properties" />
I read the local properties file first and the default one second. Users don't edit the default one (then accidentally check it in), they just define the properties they want to override in the local.properties.

You can override ant properties from the command line.
ant -Dinstall.location=/bob1 install
See Running Ant for more information.

This answer is quite late but I just wanted to put it in for someone who may be in need of of it. The answer pertains to the second part of your question.
"Can "ant install" take arguments or be configured to consider environment variables for the install target?"
Define the environment virable in your build file:
<property environment="env" />
reference the env variable and use it to indicate a path. This is done in my classpath definition inside my build file. It says include a jar named api.jar from the weblogic lib directory. You can access any other path so long as there's an associated environment virable defined for it. For example, you can access Program Files, Documents, Java Home etc if you sent environment variables for them. Here the environment variable defined for weblogic installation directory is BEA_HOME
<fileset dir="${env.BEA_HOME}/wlserver_10.0/server/lib">
<include name="api.jar" />
</fileset>

Defining properties with the -D option at the command line is fine, though it can get tedious if there are many of them frequently. In order to resist the urge to wrap the ant invocation in a bash script, there is the common practise to import property files.
In the main build file you put:
<property file="default.properties" />
Then you have a file named default.properties.sample with a sample configuration. This is being checked into version control. The developers check out default.properties.sample, copy it to default.properties and edit it according to their needs.
You should set an ignore default flag for default.samples in order to prevent it from being checked in accidentally (svn:ignore with subversion).