Summary of the idéas.
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 ---------------------------
/ 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: