[Please cc this discussion to [EMAIL PROTECTED], the mailing list for
Gcj. A goal for this dicussion is to work out a policy that GNU tools
and applications, including Gcj and automake, can implement as their
default when configured with prefix=/usr. This is is a general GNU and
FHS standardization issue, not just a Debian policy issue.]
Ola Lundqvist <[EMAIL PROTECTED]> wrote:
> Java libraries:
> * Java libraries should go to /usr/share/java if they are
> jar files and /usr/share/java/repository if they are a collection
> of classes.
This is the same as the current draft policy. On the other hand:
Joe Emenaker <[EMAIL PROTECTED]> writes:
> Well, being a big fan of Tomcat, I'd much more prefer to see .jar files in
> "/usr/share/java/lib" and .class hierarchies in "/usr/share/java/classes".
And automake does not (as far as I know) does not deal with .jar files,
and installs .class hierarchies directly in /usr/share/java.
My personal preferance is to avoid extra levels of nesting, unless they
would improve clarity or otherwise directories get too big. However,
this is not a big issue. I do think /usr/share/java/lib may be misleading,
and /usr/share/java/jar or (better) plain /usr/share/java is preferrable.
I do think /usr/share/java/classes is a better name than
/usr/share/java/repository.
I don't see anything in the Tomcat distriction about /usr/share/java/lib,
so I don't see the relevance of Tomcat. I that the src distrinution contains
.jar files in lib, but I don't think that's relevant for installation.
In fact I don't see anything in the Tomcat source about "installation"
in the GNU sense - it looks like their model is "build the stuff in
place and then have users patch PATH and CLASSPATH". I don't think
that is suitable for us.
> To prevent name clashes of .jar files, we may or may not want to
> support/encourage putting .jar files in subdirectories within
> /usr/share/java/lib.
I disagree. My goal is that that /usr/share/java (or
/usr/share/java/lib if you prefer) should be similar to Sun's
extensions directory: a directory where *all* .jars
(i.e. /usr/share/java/*.jar) are added to the implied classpath.
(This is of course a default assuming nothing is over-ridden.) Yes,
you could define a standard where all .jars in all subdirectories of
/usr/share/java (i.e. /usr/share/java/*/*.jar) but I think that is
going too far.
Ola Lundqvist <[EMAIL PROTECTED]> again:
> * The jar file should be named name-version.jar and defaults
> should be a symbolic link with the name name.jar
> Quite the same way as C-libraries.
I agree, with the note that the implied classpath should use the
"least-specific" versions (i.e. symlinks) and ignore name-version.jar
if there is a name.jar in /usr/share/java.
> > * Here is a proposal. API dependencies should be specified in
> > a way so that it should be easy to set the classpath.
Joe Emenaker:
> I'm not sure I follow you. I was under the impression that the
> /usr/share/java class hierarchy and all of the jars would be auto-included
> into the classpath whenever you run java/javac/javadoc/whatever. If that's
> the case, then dependencies don't matter since you always get the whole
> enchilada.
That should be the default. However, we need a way to specify that
version N of application X needs version M of library L. I think the
way to do that is in the .jar file itself, not a separate file or
wrapper. The "Jar Guide" mentiones an "Extension-List" attribute that
an applet can use to specify "the extensions that are needed by the
applet" and "Each extension listed in this attribute will have a set
of additional attributes that the applet uses to specify "which
version and vendor of the extension it requires". We could do something
similar for applications and libraries.
Anyway, I think using Extension-List or something similar should be
a refinement for the future. For now applications that want special
library versions should install a shell script that sets the CLASSPATH
to include the preferred jar file versions.
Ola Lundqvist <[EMAIL PROTECTED]>:
> * We should find a way to make it possible to use switch between
> java virtual machines without having to reset the classpath or similar.
> But maybe this simply is too early.
Well, each VM is responsible for setting its own builtin classpath.
> * We should find a way to make it possible to use switch between
> java virtual machines without having to reset the classpath or similar.
> But maybe this simply is too early.
Well, each VM is responsible for setting its own builtin classpath.
> Yes, yes, yes! Also, if possible, I'd like the individual users to be able
> to set an environment variable that picks which JVM gets run when they want
> to invoke a JVM. (This might be treading a little too close to the edge of
> legality, since I think Sun's Java license says something like: If the user
> types "javac", they'd better get the compiler from the JDK.)
Unless they have trademarked "javac" they don't get to say what gets
run when a user types it. The only relevant license issue I know about
is about re-distributing jdk but only as long as no part is "replaced".
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
