Importing has nothing to do with loading classes or setting CLASSPATH.

Try this:

java -cp .;../lib/* Generator

Using the dot '.' as the first entry in the CLASSPATH assumes that the Generator.class file exists in the directory from which you're running java, and /lib is one level up from that directory. Adjust as needed if both of these are not correct.

I'm not a Java programmer, so I don't know the correct value for CLASSPATH. But, you seem to. You can add it to ~/.bashrc like so:

CLASSPATH=/path/to/1:/path/to/2:/etc

The change will take effect globally the next time you log in. However, it will take effect immediately in new shells.

Additionally, if you want to set it for just one particular command, do this:

CLASSPATH=/something command-here arg1 arg2

A third way would be to create a wrapper script, which would be appropriate if you needed to set multiple variables or if you needed to determine appropriate values programmatically:

#!/bin/bash
export CLASSPATH=/something
export ANOTHER_ENV_Variable=foo

exec your_fancy_program "$@"

export CLASSPATH=/home/appnetix/LOG4J_HOME/log4j-1.2.16.jar

or, if you already have some classpath set

export CLASSPATH=$CLASSPATH:/home/appnetix/LOG4J_HOME/log4j-1.2.16.jar

and, if also you want to include current directory

export CLASSPATH=$CLASSPATH:/home/appnetix/LOG4J_HOME/log4j-1.2.16.jar:.

I don't like setting CLASSPATH. CLASSPATH is a global variable and as such it is evil:

• If you modify it in one script, suddenly some java programs will stop working.
• If you put there the libraries for all the things which you run, and it gets cluttered.
• You get conflicts if two different applications use different versions of the same library.
• There is no performance gain as libraries in the CLASSPATH are not shared - just their name is shared.
• If you put the dot (.) or any other relative path in the CLASSPATH that means a different thing in each place - that will cause confusion, for sure.

Therefore the preferred way is to set the classpath per each run of the jvm, for example:

Copyjava -Xmx500m -cp ".:../somejar.jar:../mysql-connector-java-5.1.6-bin.jar"    "folder.subfolder../dit1/some.xml

If it gets long the standard procedure is to wrap it in a bash or batch script to save typing.

Using Java 6 or later, the classpath option supports wildcards. Note the following:

• Use straight quotes (")
• Use *, not *.jar

Windows

java -cp "Test.jar;lib/*" my.package.MainClass

Unix

java -cp "Test.jar:lib/*" my.package.MainClass

This is similar to Windows, but uses : instead of ;. If you cannot use wildcards, bash allows the following syntax (where lib is the directory containing all the Java archive files):

java -cp "$(printf %s: lib/*.jar)"

(Note that using a classpath is incompatible with the -jar option. See also: Execute jar file with multiple classpath libraries from command prompt)

Understanding Wildcards

From the Classpath document:

Class path entries can contain the basename wildcard character *, which is considered equivalent to specifying a list of all the files in the directory with the extension .jar or .JAR. For example, the class path entry foo/* specifies all JAR files in the directory named foo. A classpath entry consisting simply of * expands to a list of all the jar files in the current directory.

A class path entry that contains * will not match class files. To match both classes and JAR files in a single directory foo, use either foo;foo/* or foo/*;foo. The order chosen determines whether the classes and resources in foo are loaded before JAR files in foo, or vice versa.

Subdirectories are not searched recursively. For example, foo/* looks for JAR files only in foo, not in foo/bar, foo/baz, etc.

The order in which the JAR files in a directory are enumerated in the expanded class path is not specified and may vary from platform to platform and even from moment to moment on the same machine. A well-constructed application should not depend upon any particular order. If a specific order is required then the JAR files can be enumerated explicitly in the class path.

Expansion of wildcards is done early, prior to the invocation of a program's main method, rather than late, during the class-loading process itself. Each element of the input class path containing a wildcard is replaced by the (possibly empty) sequence of elements generated by enumerating the JAR files in the named directory. For example, if the directory foo contains a.jar, b.jar, and c.jar, then the class path foo/* is expanded into foo/a.jar;foo/b.jar;foo/c.jar, and that string would be the value of the system property java.class.path.

The CLASSPATH environment variable is not treated any differently from the -classpath (or -cp) command-line option. That is, wildcards are honored in all these cases. However, class path wildcards are not honored in the Class-Path jar-manifest header.

Note: due to a known bug in java 8, the windows examples must use a backslash preceding entries with a trailing asterisk: https://bugs.openjdk.java.net/browse/JDK-8131329

When you specify -jar then the -cp parameter will be ignored.

From the documentation:

When you use this option, the JAR file is the source of all user classes, and other user class path settings are ignored.

You also cannot "include" needed jar files into another jar file (you would need to extract their contents and put the .class files into your jar file)

You have two options:

1. include all jar files from the lib directory into the manifest (you can use relative paths there)
2. Specify everything (including your jar) on the commandline using -cp:
   java -cp MyJar.jar:lib/* com.somepackage.subpackage.Main

First, in general, setting the env var CLASSPATH usually causes more problems than it solves -- since not all app's want/need the same classpath, & often break when undesired or even unneeded jars are included in the classpath. A java app should only include the minimum number of jars it requires, no more, no less.

When you have specific, individual apps that do require that the classpath be set, then usually the command-line option is preferred: java -cp path1:path2:.... Desktop icons can have their command altered to include these options, or shell scripts can be modified to include these options.

That being said (and since there are always exceptions to the rule), then depending on the version of java (this requres java 6 or later), you can specify that a whole directory of jars be added to the classpath by adding a "*" at the end of a directory; e.g, the following:

 /dir1/foo.jar:/dir2/dir3:/dir5/dir6/*:etc...

Means:

• /dir1/foo.jar - (the single jar) will be added to the classpath;
• /dir2/dir3 - all un-jar'd classes in this directory will be added to the classpath (must be in proper package structure; e.g, com.my.Foo.class must be in /dir2/dir3/com/my/Foo.class)
• /dir5/dir6/* - all jars in this directory (i.e., /dir5/dir6/*.jar) will be added to the classpath. Note that this "*" isn't a wildcard (you can't use f*.jar or even *.jar); it's a special character indicating "add all jars"

In general, if you have to add a whole directory of jars to the application's classpath, the app was not bundled correctly. Rather, the app should have a manifest containing the list of jars it depends on. Or at the very least, only one jar should be added to your classpath, and that jar can have in its manifest the whole list of jars in some subdirectory.