[gentoo-dev] Help with new Cocoon ebuild

[gentoo-dev] Help with new Cocoon ebuild

[Jörg Schaible]

Hi gang,

since I need a new Cocoon release for another package, I created a new
ebuild for it for current release 2.1.3 (my first ebuild at all). I just
took the old version for 2.0.2 and adjusted it for the current needs. While
it went fine, I am not too happy with it at all. Basically the old ebuild
just build the cocoon.war and installed it into an existing Tomcat release.
This has following problems:

- my next package is build upon Cocoon, but anything left by the ebuild are
the docs and the war file in Tomcat
- there are multiple servlet containers that can run Cocoon. In portage we
have already Tomcat, Resin, jBoss and j2eesdk. Installing Cocoon the hard
way into Tomcat is probably not what the user wants, even more, the
complete build is nonsense if he does not have Tomcat
- Cocoon can run standalone
- Cocoon is not reported as a java-package by java-config

Therefore I would like to:
- build Cocoon into /usr/share/cocoon
- provide a package.env
- support USE-flags for installation of Cocoon into existing servlet
containers or have a global virtual/servlet-container where cocoon is
installed

Looking at the ant ebuilds I can see the inherited java-pkg, but I am not
sure, what this really means or if there is any documentation. Additionally
I did not found the location of the eclasses (possibly an oversight in the
docs).

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.

Any thoughts and hints welcome!

Regards,
Jörg


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Help with new Cocoon ebuild

[Jörg Schaible]

Jörg Schaible wrote:

[snip]
> Looking at the ant ebuilds I can see the inherited java-pkg, but I am not
> sure, what this really means or if there is any documentation.
> Additionally I did not found the location of the eclasses (possibly an
> oversight in the docs).
[snip]

Finally I found it :)

Regards,
Jörg


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Help with new Cocoon ebuild

[Karl Trygve Kalleberg]

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.






--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Help with new Cocoon ebuild

[Eivind Tagseth]

* Karl Trygve Kalleberg <karltk@gentoo.org> [2004-01-09 09:18:40 +0100]:
> 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.

Looks good.

> ---
> export JAVA=`java-config -J`
> export CLASSPATH=`java-config -p commons-logging-1,bcel-0,junit-3`
> ${JAVA} org.foobar.Main $*
> ---

Just a comment:  Normally, when I want the classpath for junit, I just
want the classpath for junit.  I don't remember which version or slot of
junit I want.  How about a mechanism for automatically choosing the latest
slot if the slot is unspecified?  Kind of like the way shared libraries
work?



Eivind

-- 
Eivind Tagseth,
E-post jobb: eivind.tagseth@consultit.no, e-post priv: eivindt@multinet.no
Mobil: +47 922 43 742

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Help with new Cocoon ebuild

[Karl Trygve Kalleberg]

On Fri, Jan 09, 2004 at 09:44:38AM +0100, Eivind Tagseth wrote:
>
> > ---
> > export JAVA=`java-config -J`
> > export CLASSPATH=`java-config -p commons-logging-1,bcel-0,junit-3`
> > ${JAVA} org.foobar.Main $*
> > ---
> 
> Just a comment:  Normally, when I want the classpath for junit, I just
> want the classpath for junit.  I don't remember which version or slot of
> junit I want.  How about a mechanism for automatically choosing the latest
> slot if the slot is unspecified?  Kind of like the way shared libraries
> work?

Naturally. 

java-config would default to selecting the highest slot if none was
specified. 

However, for libraries, it is usually the case that you have to program
against a particular 'series', as both ABIs and APIs tend to break with
major revisions. 

Example: gtk 1.x vs gtk 2.x,


Kind regards,

Karl T

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [gentoo-java] Re: [gentoo-dev] Help with new Cocoon ebuild

[Thomas T. Veldhouse]

Karl Trygve Kalleberg wrote:
>
> 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.
>

So ... how does Java perform and handle monolithic CLASSPATHs?  These things
could become truly horendous in length!

Tom Veldhouse


--
gentoo-dev@gentoo.org mailing list