Sorry for the delayed reply, but we all know how life and time come and go.
On Tue, 18 Sep 2001, Ola Lundqvist wrote:
> 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).
There could be a libxalan2.3-java. It depends the software. In addition,
this means having libxalan1-java, libxalan2-java, etc.
> 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.
As this mirrors /usr/lib, this is perfectly acceptable.
> It should also provide a symbolic link of the form
> XXX[version].jar -> XXX-fullversion.jar
Drop the '-' on the link target. Standard libraries do not have anything like
that.
Example:
Package: libxalan1.jar
Version: 1.2.3
/usr/share/java/libxalan1.jar -> libxalan1.2.3.jar
Package: libxalan1.jar
Version: 1.5.6
/usr/share/java/libxalan1.jar -> libxalan1.5.6.jar
Package: libxalan2.jar
Version: 2.0.6
/usr/share/java/libxalan2.jar -> libxalan2.0.6.jar
The libxalan1.jar and libxalan2.jar symlinks would be contained in the package
directly, as this mirrors a normal -dev package. As java libraries contain
both the runtime code, in addition to nescessary info to develop with, this
makes the most sense.
Using the scriptage below, a link would be automagically created for
/usr/share/java/libxalan.jar, which would *not* be provided in each deb.
> * 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.
This is something that I agree with in principal, but not in theory.
Consider, for example, perl and python scripts. They install into /usr/bin,
and can be full scripts. They may have internal library-like code, that is
installed with the binary deb, but resides in the library directories for the
language.
However, applying this to java is problematic. The java application may
provide a small deb, that contains a Main class(as is the case for
JBoss-2.4.3_Tomcat-3.2.3/jboss/client/stop.jar), that is a call wrapper to the
actual application.
If an application wants to hide its internals, then it should not place the
jars into /usr/share/java. This would mirror the case of static .a files(see
-devel, the SDL/X thread), where the API is in flux, or not something upstream
wants to support.
Also, it may be beneficial for java-common to register .jar/.war/.ear files
with /proc/sys/fs/binfmt_misc, and provide a wrapper script for running these.
This could keep each binary package from having to have its own wrapper
script, in addition to improving the usability of java in debian.
> To discuss:
> -----------
>
> * Should we allow library packages to provide different versions?
> Like libxalan2 that provides both xalan1 and xalan2 jars.
This should be allowed, but a package can't have versioned provides, so
this should be a little used feature.
> * Should there be a script that automaticly fixes the symbolic
> links in the /usr/share/java directory.
mkdir /etc/java-common/jar-alternatives
mkdir /var/lib/java/jar-alternatives
/usr/sbin/update-alternatives \
--altdir /etc/java-common/jar-alternatives \
--admindir /var/lib/java/jar-alternatives \
--install /usr/share/java/gnu-regex.jar \
gnu-regex.jar /usr/share/java/gnu-regex-1.0.8.jar \
10
The --altdir and --admindir could be done in a very short wrapper script.
As an alternative(pun not intended) mechanism, something similiar to ldconfig
could be used. This script would scan all versioned jars in /usr/share/java,
and change the links to point to the newest version. This ldconfig-alike
would have some difficult parts to implement, as there is no such thing as a
SONAME for it to key off of.
> * Must programs also place their files in /usr/share/java.
s/Must/Most/
It may be beneficial to send this document thru a spell checker, as there are
some other mispellings and incorrect grammar usage.
> Classpath:
> ==========
>
> 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.
The wrapper should ALWAYS append the default system classpath to the provided
classpath(either thru $CLASSPATH or -classpath). However, specifing
-jdk-target <jdkname> would change the notion of the default system classpath.
Note, that the name -jdk-target is just a suggestion.
> Dependencies:
> -------------
>
> * Some sort of function should be there to get the classpath that
> a specific jar-file needs to run correctly.
Use the META-INF/MANIFEST.MF(Classpath) attribute.
> * This tool should be implemented to help the developers and
> maintainers to create a good classpath before running the jvm.
When a java binary(or library for that matter) is compiled in debian, the
debian/rules file should use the short name for the jar(see scriptage above).
Then, when producing dependencies, it calls a short wrapper around
update-alternatives --display(or --config)
Java library packages may want to provide something that looks very much like
normal <pkg>.shlibs. However, this should *not* go in /var/lib/dpkg/info, as
it would confuse automatic scanners that already exist.
Using the xalan example:
cat libxalan1.javalibs
xalan 1 libxalan1 (>= 1.2.3)
cat libxalan2.javalibs
xalan 2 libxalan2 (>= 2.0.6)
> * 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.
/etc/java/default-classpath/jdk1.1
The above is a file that contains a list of jars that are part of jdk1.1's
system classpath. This is marked as a conffile, and owned by jdk1.1.
Additionally, all jvm providers, when updating alternatives for /usr/bin/java,
need to provide additional --slave links, in addition to the manpage slaves.
For example:
update-alternatives \
--install /usr/bin/java java /usr/lib/jdk1.1/bin \
<priority> \
--slave /usr/share/man1/java.1.gz java.1.gz \
/usr/share/man/man1/java-jdk11.1.gz \
--slave /etc/java/system-classpath \
java-system-classpath \
/etc/java/default-classpath/jdk1.1
Of course, this doesn't address how a java compiler can discover which jvm to
compile for. Maybe a possible '--for-jdk jdk1.1', and the wrapper for the
compiler can then read /etc/java/default-classpath/jdk1.1.
> 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?
java --flavor
I did not choose -version, as some jvms already have that. --flavor has a
a high probability of not currently being used.
When calling --flavor, it should output a single string, that patches the name
used for the file in /etc/java/default-classpath.
> 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?
We should outlaw it's use, completely. File grave bugs on all packages that
use it, nmu a day later, and purgate the person who came up with this *LAME*
idea.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
