> -----Original Message-----
> From: Daniel Rall [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 19, 2002 12:15 PM
> To: Jakarta Commons Developers List
> Subject: Re: property naming (Re: cvs commit: jakarta-commons/digester
> build.properties.sample)
>
>
> Jeff Turner <[EMAIL PROTECTED]> writes:
>
> > On Mon, Mar 18, 2002 at 07:49:29PM -0800, Daniel Rall wrote:
> > > Why not use lib.repo instead of root? Many other projects
> are already
> >> using this variable to point to the location where Java
> libraries are
> >> rooted.
> >
> > By "library repository", do you mean a directory full of
> random jars,
> > copied or symlinked there from various projects?
>
> Exactly. Preferably with version numbers in their file names. ;-)
>
> > Is this a jar management scheme we want to encourage? :)
>
> Yes. Practice has shown me that it works extremely well. In fact,
> it's a time honored tradition, with the historical precedent dating
> back the beginnings of Unix. See /lib, /usr/lib, and /usr/local/lib
> on your favorite Unix or Linux box. Let's learn from history.
>
History has very mixed lessons on this. In particular cf /opt/<package> and
/usr/local/<package> on Unix. Also 'DLL Hell' on Windows.
The principal of /lib and /usr/lib is that they are a set of libraries
provided by the manufacturer of the system. They are not, in principal,
managed by the end user, or local system adminstrator, except for upgrades
and patches from the system manufacturer. /usr/local is maintained by the
local system administrator.
Third party packages are placed in either /opt or /usr/local, under their
own directory. Third party, meaning neither the system manufacturer nor the
system administrator.
A significant reason that unix can get away with it is because the system
loader is aware of library versions. If a binary needs version Y of a
library, it can make sure it gets it, even if the default is version Z.
The system java classloader does not provide that facility.
So, instead, we get DLL Hell.
A second issue is distribution of packages. Placing jars in CVS, or placing
them in a shared repo, tends to encourage splitting the jar from the rest of
it's distribution. Often, and in particular, including it's license. There's
been some call to include a license in a jar's META-INF, but if the author
didn't put it there, you might not even have the authority to change the jar
by doing so for them.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
