On Thu, 14 Sep 2000, Stephane Bortzmeyer wrote: > > Having a "repository" subdirectory doesn't do much to keep > > /usr/share/java clean, especially if lots of apps put jar files there. > > Yes, jars are messy, hence the "repository" subdirectory which is supposed to > stay clean (following the hierarchical naming of classes).
<slightly_annoyed> ROTFLMAO. Repository is NOT good. No way in hell. This is the most lame assed idea ever. </slightly_annoyed> I see you have never had to have 2 versions of a jar installed at the same time. If everything is unpacked in /usr/share/java/repository, then there is no way that multiple versions could be installed. This is one of debian's fine points. We can have several versions of a runtime library installed, but limit new developement(in lots of cases, but not all), to only using the latest version of the libary. With java, things are different. There is no distinction between runtime and development support(well, sorta). A .class contains not only the code, but also the method declarations, and the same command(import) is used to 'link' a java 'binary' to a 'library', and to include it's definitions. Also, there is another annoying bug, that I have discovered. It is because of this repository, that I found it. However, the bug in and of itself is not the fault of the repository. When using jikes to generated Makefile dependencies, if it finds any bare .class files, it'll try to look for the .java to match. This fails, with the unpacked classes in the repository. /usr/bin/jikes -nowrite +E +M -d ../classes/java -classpath <...> Foo.java ----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS d- s: a-- c+++ UL++++ P+ L++++ !E W+ M o+ K- W--- !O M- !V PS-- PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z? -----END GEEK CODE BLOCK----- ----BEGIN PGP INFO---- Adam Heath <[EMAIL PROTECTED]> Finger Print | KeyID 67 01 42 93 CA 37 FB 1E 63 C9 80 1D 08 CF 84 0A | DE656B05 PGP AD46 C888 F587 F8A3 A6DA 3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG -----END PGP INFO-----
