Re: packaging jars vs. classes

["Joe Emenaker" <joe@emenaker.com>]

> After some reflection it seems that it would make more sense to just
> copy the class files in /usr/share/java so setting the classpath for
> standard packages would be handled once by setting
> CLASSPATH=/usr/share/java once instead of having to tack on new jar
> file to the classpath every time a new package is installed. It
> certainly wouldn't make sense to have to mention each individual
> executable that gets installed into the path, so why do we do it for
> java?

I think I like the way Tomcat does it. Tomcat is the servlet engine from
the Apache folks. Basically, for any given web application, you can have
(among other directories) a "classes" directory and a "lib" directory.
For that application, all classes within the "classes" directory and all
.jar files in the "lib" directory will be in the classpath for that
webapp's classloader. Got a new .jar file? Toss it in the "lib"
directory, restart tomcat, and you're off and running.

It would be really nice if the maintainers of the jdk packages could
tweak the scripts that invoke that java tools so that they'd do
something like this.... auto-find all .jar files in a given directory.
In fact, what would be even nicer is if the individual users could set
an environment variable that would *also* be included. So, for example,
I could do something like:

  JAVA_PROJECT=$HOME/javathing_number_2

and, in addition to having /usr/share/java and any jar files in
/usr/share/java/repository in my classpath, I'd automatically have the
directory $HOME/javathing_number_2/classes and all .jar files under
$HOME/javathing_number2/classes/lib directory in my classpath any time I
ran any java tools.

- joe