java recipe policy for OE

java recipe policy for OE

[Robert Schuster]

[-- 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 --]

Re: 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@gmail.com

Re: java recipe policy for OE

[Robert Schuster]

[-- 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 --]

Re: java recipe policy for OE

[Paul Sokolovsky]

Hello Robert,

Friday, December 21, 2007, 2:07:54 PM, you wrote:

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

  Well, better fits java.bbclass or how you have it, IMHO, or we'd
have bitbake.conf swamped soon ;-).

> And what about
> staging. Is using ${STAGING_DATADIR}/java and
> ${STAGING_DATADIR_NATIVE}/java OK?

  I don't know much about staging personally, but that doesn't sound
wrong.

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

  No OE AFAIK. How it is usually done currently:

1. For GNU configure packages, make them actually use $prefix and
friends where they use wrong assumptions.
2. For adhoc Makefiles, patch them to use some make vars, and pass those
from .bb - via env or directly.

  You may want to see if that would make sense for your cases.

[]

> Regards
> Robert




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

Re: java recipe policy for OE

[Richard Purdie]

Hi,

On Fri, 2007-12-21 at 13:07 +0100, Robert Schuster wrote:
> Paul Sokolovsky schrieb:
> > Friday, December 21, 2007, 11:54:02 AM, you wrote:
> >> 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.

Having it fixed at runtime is fine. I'm happy with this as long as
someone could in theory change the path (just like they can change
prefix, bindir, sysconfdir etc.).

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

Yes, but call it javadir or something, the '_' character is both special
and overused and I dread to think what would happen if "java" ever made
it into OVERRIDES!

> And what about
> staging. Is using ${STAGING_DATADIR}/java and
> ${STAGING_DATADIR_NATIVE}/java OK?

No, staging is moving to a state where it matches the target system
layout. At the moment the layout_* variables don't match the target
system layout but they are going to change to. Please try and follow
that style and ask me if you need an pointers on how to do it. Poky
shows how these variables will look after the changeover.

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

Ideally we should add a function to base.bbclass to make this kind of
thing simpler.

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

The suffixes look good to me. Whilst we roughly follow debian, we don't
have to copy, if we have ideas to make it nicer, I'm all in favour ;-).

Cheers,

Richard

Re: java recipe policy for OE

[Henning Heinold]

On Fri, Dec 21, 2007 at 10:54:02AM +0100, Robert Schuster 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.

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

Hi, 

I am fine with the points, but we should see if the jni-path solution
is really practicable.

Bye Henning