| 1 |
On Wed, Jan 07, 2004 at 10:58:51PM +0100, Jörg Schaible wrote: |
| 2 |
> Hi gang, |
| 3 |
> |
| 4 |
> Also I am not sure about the strategy for the servlet container problem. If |
| 5 |
> there is a default servlet container in the virtuals, Cocoon could be |
| 6 |
> installed automatically, but I wonder if this is really what a user wants. |
| 7 |
> Cocoon itself just is a "library" with samples. The generated webapp is of |
| 8 |
> no use for production and mainly an example how to build your own webpp. It |
| 9 |
> is fine, if you can test Cocoon after installation, but that's all. |
| 10 |
> |
| 11 |
|
| 12 |
We are currently playing around with the following packaging scheme for java |
| 13 |
applications (0th draft): |
| 14 |
|
| 15 |
Each Java package will install its jar files into |
| 16 |
/usr/share/<packagename-slot>/lib/, instead of /usr/share/<packagename>/lib/ |
| 17 |
|
| 18 |
There will still be a |
| 19 |
/usr/share/<packagename-slot>/package.env file, and it can contain |
| 20 |
more than just the CLASSPATH env variable. |
| 21 |
|
| 22 |
The reason we want to use <packagename-slot> instead of <packagename-version> |
| 23 |
is to ease upgrades within a slot. If two packages with the same slot are not |
| 24 |
binary compatible, they should not be in the same slot anyway. Given the state |
| 25 |
of some packages, the full version name may need to become the slot:/ |
| 26 |
|
| 27 |
(We may need to introduce additional env files in the future, or perhaps |
| 28 |
a /usr/share/<packagename-slot>/env.d/ directory for the complex packages.) |
| 29 |
|
| 30 |
Then the idea is to update the startup scripts for the java applications themselves, |
| 31 |
so that they piece together the final classpath: |
| 32 |
|
| 33 |
run.sh: |
| 34 |
--- |
| 35 |
export JAVA=`java-config -J` |
| 36 |
export CLASSPATH=`java-config -p commons-logging-1,bcel-0,junit-3` |
| 37 |
${JAVA} org.foobar.Main $* |
| 38 |
--- |
| 39 |
|
| 40 |
For more complex packages, where we want to be able to add support for optional |
| 41 |
features at runtime (or between runtimes, without reinstalling) by simple |
| 42 |
symlinks. Example with a hypothetical package named 'java-server: |
| 43 |
|
| 44 |
In the directory /opt/java-server/packages/, we add symlinks |
| 45 |
'bcel-0' -> /usr/share/bcel-0/package.env, |
| 46 |
'common-logging-1' -> /usr/share/common-logging-1/package.env |
| 47 |
|
| 48 |
/opt/java-server/run.sh will then scan its packages/ directory, and add the |
| 49 |
relevant packages.env files to its environment before starting the server |
| 50 |
itself. (Just reading the filenames in packages/ and passing these as a comma |
| 51 |
separated list to java-config -p is sufficient). |
| 52 |
|
| 53 |
|
| 54 |
Kind regards, |
| 55 |
|
| 56 |
Karl T |
| 57 |
|
| 58 |
|
| 59 |
PS. There comments are of course welcome. |
| 60 |
|
| 61 |
PPS. There is an ongoing effort spearheaded by Dalibor Topic, involving the |
| 62 |
Debian Java team, us, kaffe.org, jpackage.org and hopefully FreeBSD and the |
| 63 |
other major Linux distros about a common java packagaging policy. Until that |
| 64 |
produces any tangible results (may be very soon), we're going to do some |
| 65 |
experiments to map out the bare minimums. |
| 66 |
|
| 67 |
|
| 68 |
|
| 69 |
|
| 70 |
|
| 71 |
|
| 72 |
-- |
| 73 |
gentoo-dev@g.o mailing list |
Archives