Package: java-common Version: 0.22 Severity: normal Hello Debian Java maintainers,
I found several typos in the Java policy. The corrections have to be taken with a grain of salt since I am not a native speaker and I know next to nothing about JAVA. This is a diff of the text version with ^^^^ to mark changed words, so you have some contexts. For some unknown reason, I have changed 'classpath' to 'CLASSPATH'. Revert it if it does not make sense. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. --- java.old Sun Dec 12 13:21:25 2004 +++ java Sun Dec 12 13:21:20 2004 @@ -38,9 +38,9 @@ emacsen-common for instance. As far as I know, the only subpolicy for a programming language, is that of Perl. - Feel free to report comments, suggestions and/or disagrements + Feel free to report comments, suggestions and/or disagreements ^^^^^^^^^^^^^ to the java-common package (<[EMAIL PROTECTED]>) - or the Debian Java mailinglist <debian-java@lists.debian.org>. + or the Debian Java mailing list <debian-java@lists.debian.org>. ^^^^^^^^^^^^ Change requests should be sent as a bug to the java-common package. _________________________________________________________ @@ -107,7 +107,7 @@ Java compilers must provide java-compiler and/or java2-compiler and depend on java-common. They must also - depend on the needed runtime environemnt (java1-runtime and/or + depend on the needed runtime environment (java1-runtime and/or ^^^^^^^^^^^ java2-runtime). They should use /etc/alternatives for the name 'javac' if they @@ -126,7 +126,7 @@ (for instance a manual page per executable, see Policy 13.1). If they have their own auxiliary classes, they must be in a - jar file in /usr/share/java. The name of the jar should folow + jar file in /usr/share/java. The name of the jar should follow ^^^^^^ the same naming conventions as for libraries. Programs must depend on java-virtual-machine and the needed @@ -144,13 +144,13 @@ Java libraries packages must be named libXXX[version]-java (without the brackets), where the version part is optional and should only contain the necessary part. The version part - should only be used to avoid naming colisions. The XXX part is + should only be used to avoid naming collisions. The XXX part is ^^^^^^^^^^ the actual package name used in the text below. Their classes must be in jar archive(s) in the directory /usr/share/java, with the name packagename[-extraname]-fullversion.jar. The extraname is - optional and used internaly within the package to separate the + optional and used internally within the package to separate the ^^^^^^^^^^ different jars provided by the package. The fullversion is the version of that jar file. In some cases that is not the same as the package version. @@ -167,7 +167,7 @@ developers should know what to add to their wrappers. This applies only to libraries, not to the core classes - provied by a the runtime environment. + provided by a the runtime environment. ^^^^^^^^ Some Java libraries rely on code written in a "native" language, such as JNI (Java Native Interface) code. This @@ -201,7 +201,7 @@ guavac, gcj and jikes, it cannot go to main. If your package itself is free, it must go to contrib. * If your binary package can run only with non-free virtual - machines (classpath has a list of free versions), it + machines (CLASSPATH has a list of free versions), it ^^^^^^^^^ cannot go to main. If your package itself is free, it must go to contrib. _________________________________________________________ @@ -211,7 +211,7 @@ The following points are discussions about the policy, either because they have to be studied more, or are controversial. - * Name and existance of the repository. It was removed in + * Name and existence of the repository. It was removed in ^^^^^^^^^ the latest version. * The symbolic links in /usr/share/java be made by a script instead, similar to the c-libraries. @@ -225,11 +225,11 @@ It should exist some tool to parse this. How should it work? Should the tool also be used to create the necessary - symbilic links needed by servlets under tomcat? + symbolic links needed by servlets under tomcat? ^^^^^^^^ - * Should there be a default classpath, similar to a + * Should there be a default CLASSPATH, similar to a ^^^^^^^^^ repository? Which jars should be included in that? A standard and one optional part? If there are a default - classpath (in the wrapper) how should it be overridden? + CLASSPATH (in the wrapper) how should it be overridden? ^^^^^^^^^ * How to check for a good enough jvm, and to select a proper one to use. Are /etc/alternatives not good enough? * Should the jvm internal classes be possible to override