Hi I'll try to summarize what have come up so far during the discussion.
Naming conventions: =================== Package naming: --------------- * Java programs should be named as any ordinary debian packages. * Libraries must (?) have the name libXXXX[version]-java (where the version part is the necessary part of the version, like libxalan2-java, not libxalan2.0.0-java). Jar naming: ----------- * All library packages must place their jars in /usr/share/java with the name XXXX-fullversion.jar. XXX is the library package name, see above. It should also provide a symbolic link of the form XXX[version].jar -> XXX-fullversion.jar If the version part is there it should provide two links, one with the version part and one without. The fullversion part can be more than the version. It can contain any extra information to make it unique. Like xalan1-1.2.3compatible.jar * Programs should also place their jars into /usr/share/java. But that is not needed because in some cases there are no need to do that. To discuss: ----------- * Should we allow library packages to provide different versions? Like libxalan2 that provides both xalan1 and xalan2 jars. * Should there be a script that automaticly fixes the symbolic links in the /usr/share/java directory. * Must programs also place their files in /usr/share/java. Classpath: ========== The problem is that there are a couple of jvms out there, and they are more or less compatible with each other. How do we solve this? Virtual machines: ----------------- There have been quite lot of discussion about the classpaths... There are a couple of things that I have found that people think is good. * If the user specifies a classpath that one should override the "system classpath". But still the "system classpath" should be there if the user does not specify enough information. This can be done in the following way: /usr/bin/java (or similar) takes the $CLASSPATH and contacinates it with the "internal" classpath for the jvm. Like, CLASSPATH=$CLASSPATH:$INTERNALCLASSPATH before running the real jvm. * All jvm:s and java compilers must follow this structure. * Or is there any disadvantages with this? Dependencies: ------------- * Some sort of function should be there to get the classpath that a specific jar-file needs to run correctly. * This tool should be implemented to help the developers and maintainers to create a good classpath before running the jvm. * It should also be possible to use it to create the necessary symbolic links, to for example tomcat. So it should probably spit out the jars that are needed, so you can do anything you want with them. Default classpath: ------------------ * This discusses the default classpath, except the classpath that are needed by the jvm. Should there be any such thing? * Ie, should we split out the packages in a "standard" part and a optional part. * Anyway they should be included in the right order. CLASSPATH=$USERCLASSPATH:$STANDARDJARS:$JVMJARS The java wrapper must implement this if it should be there. Checking the jvm: ================= There must be some mechanism to check which jvm that are currently running. And a easy way to select a good jvm. To me it seems that we should add a option to the java-wrapper to allow this, or? Repository: =========== * We should not recommend the use of the repository. It is better with a default autoinclusion directory with jar-files, see above. Does anyone disagree? I have probably missed a couple of things and probably not been very clear about the implementation. Well the parts that people do not object on, I'll include into the policy. Regards, // Ola -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------