[oe] java recipe policy for OE

[Paul Sokolovsky]

Hello Robert,

Friday, December 21, 2007, 11:54:02 AM, you wrote:

> 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.

  What you mean by "variable"? Packages represent finished software
bundles, are supposed to be installed in specific place, don't have
special requirement of being relocatable, and are not supposed to be
tweak by users besides some specially marked config files.

  Another thing, you should not assume that every distro will *build*
packages to be installed to /usr. Instead, OE offers location
variables (based on standard GNU configure path vars) for packages to
use. So, please don't hardcode /usr or something into your recipes.
Default CLASSPATH is ${datadir}/java thus (worth defining datadir_java
for that, so it was further configurable).

  So, once again, please don't hardcode paths in *your*
.bb's/.bbclass'es. But of course, patching 3rd party code to fully
adhere to this is yet another "another task". But if you can check for
this at least core components, like standard java runtime,
that would be appreciated.

  Realistic usecase? Building NSLU2 Optware like feeds for alien
systems (mostly vendor Leenooxes). OE is pretty bad on that now.
Trying to build nano, I had to patch 2-3 dependent recipes just to
have them build.

[]

> 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. :)

  Oh, these misguided debian naming conventions! (well, depends) We
already have inconsistency with this in OE. Python uses prefix, Perl -
suffixes. Chose your way ;-).

[]

> Regards
> Robert




-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com