Comments inline:
Ola Lundqvist wrote:
Hi
I have followed the java instalation issues thread. So I'l try to summarize and give some new proposals.
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. * Usage of jar files should be encouraged because they can be versioned. * 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.
Naming the jars with a package name convention would reduce name clashes. For example there may be several XML parsers with a parser.jar These should be named:
com.sun.parser.jar org.apache.parser.jar
etc.
For my own stuff I specify the package name to the first branch in the package nameing.
This convention will also encourage common classes to NOT be included in many jar files (eg javax.servlet.* or org.sax.* etc.).
I don't think this naming policy should be policed, only encouraged.
* Here is a proposal. API dependencies should be specified in a way so that it should be easy to set the classpath. I can create the bash script and place it in java-common if you like.
Perhaps /usr/share/java/foo-ver.apidep just lists what jars it depends on. And then a script generates the classpath for the developer to use. Personally I would like to have this when building my java packages.
It should also indicate JVM dependancies eg ">1.2.2 & !ibm1.3.2"
It would be good to have a common shell script include that would build classpaths and check JVM dependancies that could be included in start scripts.
Build: Is it possible to create a script that generates this automaticly? Like a dh_javadeps... It should also generate the dependencies in the control file...
Jvm: * .so files should be placed in /usr/lib * 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. * Maybe putting jvm implementation jars in /usr/share/java/$impl is the solution. Packages that proviedes similar functionality should then have the same name. like tools.jar could point to classes.zip (in jdk1.1). * Or maybe each jvm should have its own dependency file that the dependency script could use.
Java programs: * Should as before have a exec that fixes all issues. This will be easier if a dependency script is created (see above).
Have I missed something?
Regards,
// Ola
