| 1 |
* Jörg Schaible <joerg.schaible@×××.de> [2004-01-06 00:17:14 +0100]: |
| 2 |
|
| 3 |
> - my next package is build upon Cocoon, but anything left by the ebuild are |
| 4 |
> the docs and the war file in Tomcat |
| 5 |
> - cocoon runs into multiple servlet containers, we have in portage Tomcat, |
| 6 |
> Resin, jBoss and j2eesdk |
| 7 |
> - cocoon can run standalone |
| 8 |
> - cocoon is not reported as a java-package by java-config |
| 9 |
> |
| 10 |
> Therefore I would like to: |
| 11 |
> - build Cocoon into /usr/share/cocoon |
| 12 |
> - provide a package.env |
| 13 |
> - support USE-flags for installation of Cocoon into existing servlet |
| 14 |
> containers or have a global virtual/servlet-container where cocoon is |
| 15 |
> installed |
| 16 |
|
| 17 |
> Also I am not sure about the strategy for the servlet container problem. If |
| 18 |
> there is a default servlet container in the virtuals, Cocoon could be |
| 19 |
> installed automatically, but I wonder if this is really what a user wants. |
| 20 |
> Cocoon itself just is a "library" with samples. The generated webapp is of |
| 21 |
> no use and mainly an example how to build your own webpp. It is fine, if |
| 22 |
> after installation you can test the running Cocoon, but that's all. |
| 23 |
|
| 24 |
You are right, there are IMO several holes in the ebuild system when it |
| 25 |
comes to java. |
| 26 |
|
| 27 |
When it comes to web applications, there is currently a GLEP |
| 28 |
(http://www.gentoo.org/proj/en/glep/glep-0011.html) which deals with the |
| 29 |
many shortcomings of ebuild for "normal" web applications (basically, |
| 30 |
anything running under apache). Unfortunately, this GLEP doesn't mention |
| 31 |
servlets at all (I was planning to send a proposal for servlets, but |
| 32 |
never got around to it). This is a shame, since many of the issues with |
| 33 |
apache web applications are the same as for servlets. |
| 34 |
|
| 35 |
Another problem with java ebuilds in general is that the current setup |
| 36 |
cannot support slots. There are many cases when one app requires |
| 37 |
java-package-0.5.x, while another package requires 1.0.x. This wouldn't |
| 38 |
be too hard to add by changing the java-config script and the dojar |
| 39 |
functions to add a slot number to the jar-files, kind of like what is |
| 40 |
done for shared libraries. |
| 41 |
|
| 42 |
|
| 43 |
|
| 44 |
Eivind |
| 45 |
|
| 46 |
-- |
| 47 |
gentoo-dev@g.o mailing list |
Archives