[ruby-talk:12774] Re: Library packaging

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of Dave
> Thomas
> Sent: Saturday, March 17, 2001 9:40 AM
> To: ruby-talk ML; [e-mail]
> Subject: [ruby-talk:12772] Re: Library packaging
>
> [e-mail] (Yukihiro Matsumoto) writes:
>
> > |Would it be possible to use some sort of jar style packaging -
> ie distribute
> > |the folder hierarchy as one package - that way relative
> references should
> > |work. Ruby would need to change to load libraries out of .jar files
> >
> > Intresting.  Let me add it to the ToDo list.
>
> Before you do, let's discuss this a bit.
>
> The implementation of JAR files is one of the many evils of
> Java. Every time I get a new Java application, I have to add its JAR
> file to my classpath. THis rapidly becomes unmanageable.

This is probably not the place to go into a big discussion of Java, but
there is absolutely no need to use a system-wide classpath with Java 1.2 and
up, and it is in fact strongly discouraged exactly because it is
unmanageable and you get class visibility between different apps. As of 1.2,
the VM will find all its runtime classes on its own, and as for
applications, what you are typically supposed to do is start java (the vm)
and specify a classpath specific to that application. This can be done in a
relative fashion. So if I have an app with JARed libs in /lib, and some raw
.class files starting in /classes, I can have a batch file (supplied with
the app) in the root of the app structure which can start the app, with the
following contents:
----
java -cp lib/whatever.jar;somethingelse.jar;etc.jar;classes
com.whatever.package.structure.StartClass
----

Since it is using completely relative paths, this batch file / shell script
would have to be run out of the root directory of the app. If I wanted to be
able to run it from anywhere, I would use a version which requires a
one-time customization to specify the root, as follows (for windows):
-----
set APPROOT=d:\apps\myapp
java -cp
%APPROOT%/lib/whatever.jar;%APPROOT%/somethingelse.jar;%APPROOT%/etc.jar;%AP
PROOT%/classes com.whatever.package.structure.StartClass
-----


Jars have their good and bad points, but they are very handy for bundling
together related functionality. If I have a parser in a jar file, I can just
drop it into my lib dir (add a reference to it (which I may not have to do
if I am running in certain environments like a Servlet Web-App that will do
this automatically), and I can immediately start using its functionality,
without the issue of manageing 200 odd separate class files. If I want to
stop using it, I can remove it easily.