> On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote: > My solution to the above problem is at: > > http://newgate.socialchange.net.au/~jeff/jpe/
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 put > > the mysql-jdbc jar in every project's lib directory. Just about everything I > > do in Java on linux involves mysql-jdbc. It'd be much easier for me to just > > put it in a system-wide repository. > > But that's you, and the next user might want an older or newer version of > mysql-jdbc.jar. 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, I'd > > consider the *machine* to be broke. :) The solution would be to *fix* the > > 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/commons-beanutils.jar > Adding /home/jeff/tc/webapps/struts-tiles/WEB-INF/lib/commons-collections.jar > Adding /home/jeff/tc/webapps/struts-tiles/WEB-INF/lib/commons-digester.jar > 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. - Joe
