Re: The evils of /usr/share/java/repository
> 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
Reply to: