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

Summary of the idéas.


I'll try to summarize what have come up so far during the

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.


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.

  the real jvm.
* All jvm:s and java compilers must follow this structure.
* Or is there any disadvantages with this?


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


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


// Ola

 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Björnkärrsgatan 5 A.11   \
|  opal@lysator.liu.se                 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 /

Reply to: