Karl Trygve Kalleberg wrote: > 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:/
Are you aware of Maven? This is also a build tool for Java apps and I know meanwhile some of them using it. Basically the Maven community maintains a repository for Java archives (currently at http://ibiblio.org/maven), that will never (!?!) be cleared from old versions. Maven builds an app according to a project description that contains dependencies. The dependent archives are downloaded into a local repository during the build. What has this to do with portage? Well, if I would like to create an ebuild e.g. Apache Merlin from the Avalon project, I will have to use Maven within the ebuild, since the build generates its own Maven plugins used in the build itself again (and this is common for Maven builds). Additionally all dependent archives will ignore portage at all and download the Java archives from ibiblio (and cache them in a local repo). The difference to portage is, that each dependency references always the exact version of the dependen archive. And this is often a snapshot from a specific date. I've build enough apps based on the Apache stuff and normally all the versions are not binary compatible and will break stuff, sometimes very subtile. The dependency system of Maven gives you at least a chance to have a running app ... > (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). Well, do not forget EARs or WARs. You have to modify sometimes the classpath before you start the server. The problem is: Into which app server or servlet container should an ebuild for such an application merge the application ... Kind regards, J�rg > PS. There comments are of course welcome. I really do not want to be destructive, but looking at the Java archive mess, sometimes the Windows DLL hell comes into my mind ... > 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
