java recipe policy for OE

[Robert Schuster <theBohemian@gmx.net>]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

Hi,
the toolchain stuff has not been committed yet but I still want to start
a little discussion about the future of java packages in OE.

a) jar location
The Debian java packages have the fine habit of placing all the jars
(this is what resembles a shared library in java land) into
/usr/share/java. Since Java (still) lacks an automated mechanism to look
up those jars they have to be provided manually when starting an
application (e.g. through a shell script) and putting them into a common
directory saves people's nerves.

Making the jar location variable is easy, making applications work can
be hard (patching scripts etc). I don't see much value in making this
configurable either.

b) jni library location
Another addition from the Debian guys is to put JNI libraries (shared
libraries which provide some C stuff to the Java side) into
/usr/lib/jni. Native library lookup is even more strange in Java and it
was decided to simply patch Java runtimes to add /usr/lib/jni to the
default native library search path (hard coding).

Making this location configurable is difficult since it would involve
making the patches for the Java runtime configurable.

If OE follows both approaches I hope that people will have it easier to
use start scripts from Debian or Debian-aware projects on their devices.

c) naming
Debian names packages containing only jars lib<PN>-java. If it has a
corresponding JNI library it is called lib<PN>-jni. I would like to
adopt this for OE. With the help of a bbclass for java library recipes
this safes boilerplate. I have an early version of such a bbclass in the
Jalimo repository for everyone to look at, criticise and enhance. :)

For those coming from the C world these suggestion may look quite strict
but please keep in mind that compiling Java package from source is often
a complete mess: Source tarballs often contains pre-built dependencies
of some unknown version and every project has its own special way of
being built. So it is already very complicated to write proper OE
recipes for those. Making the policy for Java packages as strict as
explained above gives us the possibility to patch every out of place
source tarball into obedience. :)

Regards
Robert


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]