[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Java libraries and proposal.

Comments inline:

Ola Lundqvist wrote:


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:



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.

  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...

* .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?


// Ola

Reply to: