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

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: