Re: Build an installable package with NetBeans
bruce wrote:
Anyhow, I can now run my application from the command line. I added
mysql-connector-java-5.1.13 to my system CLASSPATH.
Which brings to mind a question! Should I leave mysql-connector-
java-5.1.13 in my system CLASSPATH or move it to my Java CLASSPATH?
John B. Matthews wrote:
I've put JARs in one of the java.ext.dirs in the past, but it inevitably
leads to problems. It's best to specify the class path either via the
command line or in the JAR's manifest.
Classpath management is one of the arcane sciences. It is well worth the time
to read up on it. Links and summary:
<http://download.oracle.com/javase/6/docs/technotes/tools/solaris/java.html#options>
"-jar ... When you use this option, the JAR file is the source of all user
classes, and other user class path settings are ignored."
<http://download.oracle.com/javase/tutorial/deployment/jar/downman.html>
<http://download.oracle.com/javase/tutorial/deployment/jar/manifestindex.html>
<http://download.oracle.com/javase/6/docs/technotes/tools/solaris/jar.html>
<http://download.oracle.com/javase/tutorial/essential/environment/paths.html>
java.ext.dirs serve a special, special purpose. An extension is not a simple
classpath element. It transforms the Java platform itself into a
special-purpose environment. It applies to every regular application. (I'm
pretty sure the "-jar" classpath blockage applies to extension directories,
however.) In effect, extensions become part of Java itself for that platform.
Regular classpath elements are nodes for conventional libraries. Regular
classpaths are those specified in the CLASSPATH envar, tools' "-classpath" and
"-cp" options, and JAR manifests when run under "-jar".
CLASSPATH, like extensions, applies to all non-"-jar" executions, regardless.
It's convenient when you really do want to specify common library search
paths for all Java things at a level less than extending the platform. I
consider this need rare.
Classpath tool options are best for running Java things under the control of
your local preferences. A command "java -cp <whatever> ..." gives the
invoking Java control of the classpath. It's far more flexible than the
CLASSPATH envar.
JAR manifest "Class-Path:" serves the primary purpose of a JAR - to provide a
self-contained delivery mechanism for a library or application. It overrides
the invoking "java" classpath to give the JAR itself command of the classpath.
The catch to JAR manifest "Class-Path:" is that the referenced library JARs
have to live outside the commanding JAR in the host filesystem, not within the
JAR itself. A full JAR-based deployment would be something like a ZIP holding
the application JAR and its helper JARs in relative paths to the main one.
The user unpacks the ZIP into a target directory on their system and voil??.
That's downward-relative. Use of "../" in JAR paths is ill-advised. Same
directory or relative "lib/" are two suggestions.
--
Lew