Re: Proposed Debian policy for Java
Hi
(I CC the debian-java list)
On Fri, Sep 20, 2002 at 02:47:07AM +0100, Alex Blewitt wrote:
> o java-compiler, java2-compiler: I don't think it's necessary (or even
> desirable) to distinguish between java and java2 at all, especially as
> the '2' trademark doesn't have any sensible correlation between the
> version numbers. It was basically a trademark that Sun used to
Well I can agree on that.
> encourage uptake of Java in business. I'd suggest having java-compiler
> and java-virtual-machine, and then use the version numbers (1.2, 1.3,
> 1.4) to denote different systems. If there are any specific
> requirements on Java apps they can then distinguish it by >= 1.2
> instead of relying on java2. [I also don't know of any java1-only
> systems either :-)]
I'm afraid that is not possible with the current virtual-package system
and dpkg, apt-get and dselect. There is no such possibility. :(
I have requested it (I think) but that will probably not be available for
a number of releases...
> o Java programs in /usr/bin - how does this relate to java packages? If
> I have a class com.ioshq.Test, then it expects to be in a directory
> structure com/ioshq/Test, which doesn't fit in with the /usr/bin policy
> described. Also, some executables are JAR files (which I don't know if
> they count as executables) though it could be advisable to create
> scripts to launch common apps, and put them in /usr/bin
You have to have the executable in /usr/bin. As policy says it should be
a wrapper to execute the java program. Is it unclear?
> o Java libraries. Many Java applications need both JARs, but also
> access to files (configuration files, workspace etc.). This policy
True.
> doesn't seem to address that. It would be better if a directory was
It does not because the "normal" policy do that in a quite good way.
> used with a well-known JAR file was included, such as
> /usr/share/java/xerces/xerces.jar, which can then have other
> non-polluting config files as well. Note that a JAR can refer to other
Why?
> JARs in the Manifest (using the Class-Path property) and generally do
Yes java2 can. Not java1. This is a big problem in fact.
> so by expecting a <name.jar> to be available. Using the proposed
> packaging name guidelines, it is likely that most JARs will not be
> usable after this approach since the system will not be able to find
> those names.
I do not understand this? The package maintainer have to make sure
that the manifest file is correct, right?
> o Use of different versions - some packages may depend on xerces1, some
> may depend on xerces2. Can this be resolved in a neat way using version
> numbers, or does the package have to be removed?
You have to have two different package (as right now).
> o JNLP - this has not been discussed in the Java Policy, and packagers
> should probably be encouraged to create JNLP interfaces for their
> programs.
What is JNLP?
> Hope this is useful; if you want more detailed explainations of the
> above points then please drop me a mail and I'll try to be a bit more
> descriptive.
It is always useful to get new information about this matter and I
really appriciated all feedback I can get. Especially constructive
as yours.
Regards,
// Ola
> Alex.
>
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Annebergsslingan 37 \
| opal@lysator.liu.se 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +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: