> Why not just put the jars in /usr/share/java, keep the system classpath > completely clean, and let the startup scripts for individual apps choose which > to include?
Well, keep in mind that the original e-mail that started this thread argued that Debian was a *developer*-unfriendly system. When developing Java apps, there *is* no startup script, initially, you gotta either write the script yourself or edit the classpath. And we're just talking about *running* the app, right? Keep in mind that you also need to compile them (again, I'm coming from a developer's perspective). So, you either need to make a script that sets the classpath and runs the compiler or you need to set the classpath yourself. If you choose to use scripts, then that's at least two scripts (one for running the app and one for testing). If you don't want to make changes to two classpath lines (one in each script), you could make *three* scripts (one that sets the classpath... which is called by the other two before they do the rest of their stuff). Of course, you could condense all of this down into a single script that either compiled or ran the app based upon command-line parms. Once you had that script working, you wouldn't want to write it over again so, with every new Java project you started, you'd want to just alter the existing one.... trying to make sure that you changed everything in the script that was project-specific. Are we having fun yet? I'm not. I guess I should add here that I do all of my Java development from the command-line. I use 'vi' or 'JEdit" as my editor and javac as my compiler. So, no tool automatically sets my classpaths for me. If I have about 4 xterms open doing different things, and I download a .jar file that I need, the classpath in all of those xterms needs to be updated. Make-ish tools like 'ant' have made this easier to manage, but I still think that there's a better way. It's not like this is without precedent. I actually got the idea from Tomcat (well, I guess I really got the idea from Java's Servlet 2.2 spec... but Tomcat is where I first became aware of it). In there, webapps are encapsulated in directories within which you have places to stick .jar files. Upon running Tomcat, all of the .jars in that webapp's 'lib' directory will be available to that webapp. > A system classpath represents an unchallenged assumption. When writing new > code, I could be unwittingly relying on stuff in the system classpath, and when > I try to compile the same stuff at work, it will all break. Well, you'd have to be a little judicious about where you placed your .jars (in the system-wide .jar respository or in app-specific repositories). The nice thing about the servlet 2.2 spec is that, if you put your obscure .jar files in your app-specific directory and your common ones in the system-wide one, then you should be able to just .jar up your entire webapp, un-jar it somewhere else, and have it work. All of its quirky stuff will have come along. 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. 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. - Joe
