Re: The evils of /usr/share/java/repository

[Jeff Turner <jeff@socialchange.net.au>]

On Mon, Sep 17, 2001 at 08:44:11AM -0500, Ben Burton wrote:
> 
> > My mistake; only java.* works. If you want other jars to be considered
> > "standard", put them in $JAVA_HOME/jre/lib/ext/. This is a
> > platform-independent equivalent of what you're proposing.
> 
> But not JVM-independent.  Bear in mind that we need a solution that works
> for all JVMs out there, including kaffe, orp, etc.

Good point.

[..] 
> Putting things in /etc/profile is dangerous because not everyone uses
> bash.
> 
> >From debian policy 10.9:
> 
> "A program must not depend on environment variables to get reasonable
> defaults. (That's because these environment variables would have to be set
> in a system-wide configuration file like /etc/profile, which is not
> supported by all shells.)"
>
> I would argue all classpath manipulation should be done in JVM/compiler
> startup scripts and Java application startup scripts.

I think you're right.

I have two questions of whatever solution is accepted:

 1) What happens when classpath conflicts arise? Say I've installed
 package 'lib-foo-java'. I now download two programs from their
 respective CVSs. One requires foo.jar v1, the other requires foo.jar
 v2. How is it possible for both apps to be able to run on my system?

Assuming there is a decent answer to that, and people agree that a
system classpath is a Good Thing:

 2) How can I override the system classpath?


--Jeff

> Jython is done this way; the jython wrapper adds in the servlet jar and
> the editline wrapper jar, then the JVM script adds in the bootstrap
> classes and off we go.
> 
> Ben.