From: Paul Sokolovsky <pmiscml@gmail.com>
To: Robert Schuster <theBohemian@gmx.net>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: java recipe policy for OE
Date: Fri, 21 Dec 2007 13:38:16 +0200 [thread overview]
Message-ID: <489984884.20071221133816@gmail.com> (raw)
In-Reply-To: <476B8D3A.7010703@gmx.net>
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
next prev parent reply other threads:[~2007-12-21 11:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-21 9:54 java recipe policy for OE Robert Schuster
2007-12-21 11:38 ` Paul Sokolovsky [this message]
2007-12-21 12:07 ` Robert Schuster
2007-12-21 13:04 ` Paul Sokolovsky
2007-12-21 14:46 ` Richard Purdie
2007-12-21 11:38 ` Henning Heinold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=489984884.20071221133816@gmail.com \
--to=pmiscml@gmail.com \
--cc=openembedded-devel@lists.openembedded.org \
--cc=theBohemian@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.