Re: The evils of /usr/share/java/repository
On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote:
> > 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.
I'm also a vim+javac programmer.
My solution to the above problem is at:
http://newgate.socialchange.net.au/~jeff/jpe/
"This page describes a simple system for working on multiple Java
projects under GNU/Linux, in particular for managing project
classpaths."
Other people just invoke Ant from their editor, and let it worry about
classpaths.
> 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.
In project-specific instances, where conflicts cannot arise, it's a nice
convenient mechanism. I've appended what my script does when I type
"proj.sh" in a webapp's directory [1].
> > 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.
You mean the 2.3 spec ;) The 2.2 spec puts $TOMCAT_HOME/lib/* before
WEB-INF/lib/*, causing lots of grief.
The 2.2 situation is a nice little analogy though. The $TOMCAT_HOME/lib is
like the system classpath. If there's a library in there (say JAXP 1.0), then
webapps requiring later versions (say JAXP 1.1) will break. To ensure that no
webapps will ever break, nothing can be put in it. Same with system
classpaths.
> 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. It would be safer to create a ~/jars directory, and then put
some stuff in your .bash_profile:
for jar in ~/jars; do
export CLASSPATH=$CLASSPATH:$jar
done
> 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? :)
--Jeff
> - Joe
>
[1]
[jeff@kermit struts-tiles]$ proj.sh
Warning: no .projrc found
-------------------------------------------------------------
Java Project Environment: version 1.29, 2001/08/03 04:10:58
-------------------------------------------------------------
Proj name: struts-tiles
Proj alias: struts-tiles
Proj author: jeff
Proj description:
-------------------------------------------------------------
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
Setting cdc alias to
Reply to: