Re: java recipe policy for OE

[Robert Schuster <theBohemian@gmx.net>]

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

Hi Paul.

Paul Sokolovsky schrieb:
> 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.
Yes, I was only talking about being variable/configurable at build time.

>   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).
Yes, I am using ${datadir}/java everywhere. ${datadir_java} would be no
problem either. Should that go into bitbake.conf? And what about
staging. Is using ${STAGING_DATADIR}/java and
${STAGING_DATADIR_NATIVE}/java OK?

> 
>   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.
That would be possible. Is there a nice way to preprocess a patch? I
would like to run sed on it to replace the hard coded path.

>   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.
Yes, have seen the optware stuff. Would be funny to retrofit
proprietarisied ... err vendor LXes with our packages. ;)

> []
> 
>> 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 ;-).
Oh well. Adhering to the Debian rules makes java-gnome
libjava-gnome-java which isnt exactly what I call a nice package name.
Still for many other packages it is OK and in regard to the JNI packages
I think it makes sense to use suffixes.

Regards
Robert


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