Hallo!
I've heard you've been in touch with Dalibor Topic. I would like to
participate in that discussion ("0th Draft"), as debian-java was also
trying to solve the same problems and came up with similiar solutions.
It would be grat. If we could agree on one standard, so that users can
get used to one way to use java apps.
* Karl Trygve Kalleberg <[EMAIL PROTECTED]> wrote:
> Each Java package will install its jar files into
> /usr/share/<packagename-slot>/lib/, instead of /usr/share/<packagename>/lib/
> There will still be a
slot beeing the _API_ Version?
> /usr/share/<packagename-slot>/package.env file, and it can contain
> more than just the CLASSPATH env variable.
This all sounds like exactly like the result of the proposal
descusion, which has taken place last year on debian-java. The only
difference is, that we (want to) use
/usr/share/java-config/<package-name>[<version>] as the config file.
> (We may need to introduce additional env files in the future, or perhaps
> a /usr/share/<packagename-slot>/env.d/ directory for the complex packages.)
the proposed solution on debian systems is to use a preinst script to
setup a contributed classpath for one package.
package A contributes its jars to package B:
java-config file for A looks like this:
--8<---------:- snip -:---------8<---------:- snip -:---------8<--
JARS="/usr/share/java/first.jar:/usr/share/java/second.jar"
DEPENDS="junit libant1.5"
CONTRIB="package_B"
--8<---------:- snip -:---------8<---------:- snip -:---------8<--
install A -> preinst -> update-java-config -> java-config file for
package B gets updated.
When constructing the classpath for package B, it will contain the
jars from package A, B, junit and libant1.5 (and all jars of all
packages, which these packages depend on).
> Then the idea is to update the startup scripts for the java applications themselves,
> so that they piece together the final classpath:
[...]
Looks not far away from our proposal:
JAVA="$(findjava --server KnownWorkingJVM1 knownWorkingJVM2)"
export CLASSPATH="java-config --all
>For more complex packages, where we want to be able to add support for
>optional features at runtime (or between runtimes, without
>reinstalling) by simple symlinks. Example with a hypothetical package
>named 'java-server:
> In the directory /opt/java-server/packages/, we add symlinks
> 'bcel-0' -> /usr/share/bcel-0/package.env,
> 'common-logging-1' -> /usr/share/common-logging-1/package.env
Hm, I'm more for in favour to do that at runtime and one a per user
base:
runApp.sh
--8<---------:- snip -:---------8<---------:- snip -:---------8<--
OPTIONAL_PACKAGE=""
[ -r $HOME/.apprc ] && source $HOME/.apprc
CLASSPATH="$(java-config --all $OPTIONAL_PACKAGES package1 package2)"
JAVA=$(...)
$JAVA -classpath $CLASSPATH com.example.Main
--8<---------:- snip -:---------8<---------:- snip -:---------8<--
where $HOME/.apprc contains a line like
|OPTIONAL_PACKAGES="optional1 optional2"
I'm don't like using symliks for configuration purpose. IMO plain text
files are much better suited to do that. Especially if you want to add
user configurations too. JPackage trys to do that via a
$HOME/.something/package/env.d/ like system. IMO only a few
applications require such configurateable classpath (ant comes to my
mind) and I don't think that one need to support such things for all
packages.
> PPS. There is an ongoing effort spearheaded by Dalibor Topic, involving the
> Debian Java team, us, kaffe.org, jpackage.org and hopefully FreeBSD and the
> other major Linux distros about a common java packagaging policy. Until that
> produces any tangible results (may be very soon), we're going to do some
> experiments to map out the bare minimums.
So, lets try :)
You can find the debian proposed policy on www.katzien.de/debian/java/
-> grap the tar.gz, which has the source for all the tools and the
proposed policy.
Jan
--
[EMAIL PROTECTED] mailing list
