Re: The evils of /usr/share/java/repository
> On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote:
> My solution to the above problem is at:
Well, I guess what I'm hoping for is to make the learning curve less steep.
I envision being able to download some java source onto a fresh Debian
system with the JDK (or alternative compiler) and being able to type
"javac". If there are missing classes, I can hop on the web, download a .jar
file, save it to /usr/share/java/lib or something, and type "javac" again
and have the compilation work this time. No studying someone's senior thesis
about the optimum way to manage classpaths, no having to install 'ant', and
no cursing about typos when changing CLASSPATH by hand.
> The 2.2 spec puts $TOMCAT_HOME/lib/* before
> WEB-INF/lib/*, causing lots of grief.
Oh, you're right. That's bad.
The lynchpin to what I'm proposing is that narrower-scope things are allowed
to pre-empt wider-scope things.
> > Now, without a system-wide .jar repository, that means that I'd need to
> > the mysql-jdbc jar in every project's lib directory. Just about
> > do in Java on linux involves mysql-jdbc. It'd be much easier for me to
> > put it in a system-wide repository.
> But that's you, and the next user might want an older or newer version of
Oh, I know. Everybody's got their own jars and stuff that they always rely
upon. I'm saying that it should be easy to make jars available to everybody
without individuals having to dick with their rc scripts or 'build.xml'
files or whatever... and that it should be easy for users to override those
system-wide jars when the need arises... and that it shoud be easy for users
to override their own user settings for individual projects. Easy, easy,
easy is the notion here. And, if you're careful about the order of
pre-emption, then I've yet to see a major problem with Debian's java scripts
auto-discovering jars for us.
> > If, like you said, I brought a webapp in
> > to my workplace and tried it on a machine that didn't have mysql-jdbc,
> > consider the *machine* to be broke. :) The solution would be to *fix*
> > machine by putting mysql-jdbc in the system-wide repository.
> And if you're not the sysadmin? :)
I'd use user-level and project-level repositories to pre-empt the
system-wide ones (which, of course, would only affect me). In the case of my
example, I'd drop mysql-jdbc.jar into $JAVA_USER_LIBS or $HOME/java/lib or
$HOME/java/repository, or whatever the hell it ends up getting called if,
indeed, it does get put in at all. If the sysadmin comes along later and
puts in some messed up or old version of the mysql-jdbc, it wouldn't affect
me any because the script that builds the classpath would have put my stuff
in front of the system stuff.
> Adding directories to classpath
> Adding /home/jeff/tc/webapps/struts-tiles/WEB-INF/classes
> Loading jars from /home/jeff/tc/webapps/struts-tiles/WEB-INF/lib
> Adding /home/jeff/tc/webapps/struts-tiles/WEB-INF/lib/struts.jar
> Adding /home/jeff/tc/webapps/struts-tiles/WEB-INF/lib/tiles.jar
Yup. Autodiscovery. I've written a script a few times that does the same
thing. I'll bet *thousands* of other people have, too. That's the problem;
thousands of people writing almost the identical script... differing only in
the names of the directories (you use
"/home/jeff/tc/webapps/struts-tiles/WEB-INF/lib" and I use
"/home/jemenake/projects/java/lib"). Part of what I'm suggesting is that
*one* person write this script *one* more time and that they write it so
that all you and I have to change is some env variable or something to tell
the script where our "personal" jars are. Then, build the script into
whatever invokes the JVM.