JBoss without packaged jars
From Gentoo Linux Wiki
Updated by Joshua Nichols <nichoj at alum.rpi.edu> on 8-30-2005
Originally by Mark Wolfe <mwolfe at netspace.net.au>
Contents |
[edit] Introduction
Based on the Gentoo Java policy, the existing ebuild for JBoss needs to updated to build without using bundled jars. Version 4.0.2 has been nominated as the first version that will follow this policy. In the future, work may also be done to move the 3.2.x release to follow this policy as well.
Creating a Java package of this size, with it's numerous dependencies, is quite a feat. This page details the progress and status of the new JBoss ebuild, and will also discuss design choices made in creating the ebuild.
[edit] Dependencies
A significant amount of progress has been made towards packaging JBoss's dependencies. Some have made it to the official Portage tree, while many live in the experimental overlay.
Remaining packages, and hurdles to packaging them:
- apache-addressing: uses maven to build
- apache-scout: uses maven to build
- apache-wss4j
- jacorb: bundled jars appear to be patched from official release
[edit] Splitting up JBoss
One major hurdle to packaing JBoss is the fact it is organized into a number of separable modules. When things really start to get hairy is when some package uses one of the JBoss modules, and then another JBoss module depends on aforementioned package. The most significant example of this would be Hibernate 3 using jboss-cache.
The solution to this was to individually package the modules (of which, there's about 30ish). This does add some extra effort to packaging, but it allows a package to depend make use of a JBoss module, without having to depend on all of JBoss.
Much of the overhead of separately packaging the modules has been alleviated by creating an eclass for them. TODO: Provide information about how the eclass works
[edit] Status
8-30-2005:
- Most of the modules have been successfully packaged. The only two that remain are varia and console (which depends on varia). The major hurdle encountered with varia is that it uses some static functions of a class provided by the common module, but it can't resolve these functions. I really see no reason while it shouldn't be able to resolve them.
- The above section for dependencies lists what still needs to be packaged. I work around them not being packaged by making a tarball containing just those bundled jars.
- Assuming varia can be fixed, the next major task will be to put all the modules together to get the actual server. Unfortunately, I don't think we'll want to use the build.xml to do this. This is because we'll end up moving stuff around and replacing jars with symlinks anyways (and ant doesn't handle symlinks), so we may as well do it ourselves.
[edit] Random Tips
Finding the version of software inside a jar:
markw@rover lib $ ls README avalon-framework.jar logkit.jar markw@rover lib $ jar -xvf logkit.jar META-INF/MANIFEST.MF extracted: META-INF/MANIFEST.MF markw@rover lib $ cat META-INF/MANIFEST.MF Manifest-Version: 1.0 Created-By: Apache Ant 1.5.1 Extension-Name: avalon-logkit Specification-Vendor: Apache Software Foundation Specification-Version: 1.0 Implementation-Vendor: Apache Software Foundation Implementation-Vendor-Id: ASF Implementation-Version: 1.2 <-- This is the version of the software here!!
