Re: The evils of /usr/share/java/repository
Joe,
On Mon, Sep 17, 2001 at 07:13:46PM -0700, Joe Emenaker wrote:
>
> > On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote:
> > My solution to the above problem is at:
> >
> > http://newgate.socialchange.net.au/~jeff/jpe/
[snip]
> The lynchpin to what I'm proposing is that narrower-scope things are allowed
> to pre-empt wider-scope things.
Great, that would mostly solve my problem.
My immediate concern is that there's currently no way to override a
classpath set in /usr/bin/java. I think that currently, everyone (even
deviant thinkers like Per;) agrees that an override is necessary.
>
[snip examples of user-stuff overriding system stuff]
>
> > 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
>
> Yup. Autodiscovery. I've written a script a few times that does the same
> thing. I'll bet *thousands* of other people have, too. That's the problem;
> thousands of people writing almost the identical script... differing only in
> the names of the directories (you use
> "/home/jeff/tc/webapps/struts-tiles/WEB-INF/lib" and I use
> "/home/jemenake/projects/java/lib").
Well.. the the point of my script is that, whichever directory you're
in, it will add the jars from that project's lib/. I didn't customize a
thing for the example above.
So if you're in /home/jemenake/projects/java/, and type "proj.sh"
(proj.sh must be in your PATH), then lib/* will be added to your
classpath, along with any other dirs which your /etc/projrc considers
"default".
If your projects are self-contained (lib contains all required jars),
then this "proj.sh" mechanism is all that's required. The convenience of
a system classpath becomes unnecessary, because you can instantly get a
project-specific classpath at any time.
> Part of what I'm suggesting is that *one* person write this script
> *one* more time and that they write it so that all you and I have to
> change is some env variable or something to tell the script where our
> "personal" jars are. Then, build the script into whatever invokes the
> JVM.
As long as it's not purely additive. I want to be able to remove stuff
from the classpath, not just add my stuff. There are various subtle
problems that can occur otherwise:
- Say lib-foo-java version 2.0 completely removes a class that
previously existed in version 1.0. If I have 1.0 in my system
classpath, then even if I override it with 2.0, the extra class from
1.0 is still in my classpath. This will cause sealing violations if
the jar is sealed (think jaxp.jar).
- Say my system classpath contains xerces 1.4.0. I require a bugfix in
xerces 1.4.1, so I should put that in my project classpath. But say I
screw up the syntax, or my 1.4.1 jar is corrupt, or I simply forget;
my app will superficially work with 1.4.0 and I'll be none the wiser
until it dies unexpectedly. I then spend all weekend tracking down
what *looks* like a bug, but is really an environmental issue. Sure
it sounds stupid, but I've done it before, and I'd much prefer for
things to die properly.
Problems like these may only bite 1 user in 100, but they effectively
mean:
- I cannot develop apps without unknowingly relying on a system jar.
- I cannot deploy apps to a Debian box, and be completely confident
that the system classpath won't cause obscure problems due to
classpath conflicts.
Whether the advantage in terms of ease of use outweighs this, it up to
you. But as I hope my script demonstrates, having a system classpath is
not the *only* way to avoid mucking with classpaths.
--Jeff
> - Joe
Reply to: