On Wed, Jan 07, 2004 at 10:58:51PM +0100, J�rg Schaible wrote:
> Hi gang,
>
> Also I am not sure about the strategy for the servlet container problem. If
> there is a default servlet container in the virtuals, Cocoon could be
> installed automatically, but I wonder if this is really what a user wants.
> Cocoon itself just is a "library" with samples. The generated webapp is of
> no use for production and mainly an example how to build your own webpp. It
> is fine, if you can test Cocoon after installation, but that's all.
>
We are currently playing around with the following packaging scheme for java
applications (0th draft):
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
/usr/share/<packagename-slot>/package.env file, and it can contain
more than just the CLASSPATH env variable.
The reason we want to use <packagename-slot> instead of <packagename-version>
is to ease upgrades within a slot. If two packages with the same slot are not
binary compatible, they should not be in the same slot anyway. Given the state
of some packages, the full version name may need to become the slot:/
(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.)
Then the idea is to update the startup scripts for the java applications themselves,
so that they piece together the final classpath:
run.sh:
---
export JAVA=`java-config -J`
export CLASSPATH=`java-config -p commons-logging-1,bcel-0,junit-3`
${JAVA} org.foobar.Main $*
---
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
/opt/java-server/run.sh will then scan its packages/ directory, and add the
relevant packages.env files to its environment before starting the server
itself. (Just reading the filenames in packages/ and passing these as a comma
separated list to java-config -p is sufficient).
Kind regards,
Karl T
PS. There comments are of course welcome.
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.
--
[EMAIL PROTECTED] mailing list
