Intro

For my 0.3 Release I packaged 3 dependencies of JBoss: one that didn’t exist in Fedora, one from JPackage and updating one that was already in Fedora. For this, I wrote a package for XML Im/Exporter from scratch, AOP Alliance’s Java/J2EE Aspect Oriented Specifications from the JPackage project and updated the Fedora Package for Apache Commons Validator. I have the source packages located on my matrix account (http://matrix.senecac.on.ca/~jhford/fedora). I am not hosting built packages as these are very easy to build (rpmbuild –rebuild *.src.rpm). For each package I have done a successful mock build and a successful koji scratch build using Sun’s bytecode compiler.

XML Im/Expoter

This package is used to import and export xml to and from Java classes. It is used by JBoss. Packaging this project caused a minor headache because during the build, all unit tests are run. When this is run using a normal rpmbuild -ba build, it passes and runs fine. When it is built by mock, it fails on one test (“XMLWriterTest”). I tried many things to get it to pass to no avail. My initial suspicion was that the class was importing org.xml.sax but there was no implementation. I researched two different implementations (TagSoup and Jaxen) and even with them both being installed in the mock environment due to being BuildRequire:’d, it didn’t want to run. I later consulted another package spec file and found out that the common trend was to not halt the build on a unit test failing. I decided against this as it is only one unit test that is failing. My solution was to remove the unit test in the preparation (%prep) stage.

AOP Alliance

This package is the standards for Aspect Oriented Programming for the Java language and is used by JBoss to enable Aspect Oriented Programming. For this package I based my work on the existing JPackage spec file and patches. After making this spec file follow the Fedora packaging guidelines I built the package and tested it using mock and koji. It built successfully on all supported platforms. The only issue which I encountered was with GCJ support. I find that I am unable to build some packages with the GCJ support enabled and to get around this, I am commenting out the existing rpm macro for “gcj_support” and defining this as 0 to disable it. After doing this, my packages are building as noarch instead of i386 as they are using Sun’s compiler. This package has shown me that importing JPackage packages is not a huge process, it is mainly the initial stanzas with information on the package which need changing.

Apache Commons Validator

This package is the Apache Commons Project Validator. It is used to verify input in a localized manner and provides localized error messages. It existed in Fedora and I used this as an example of a package which needed to be updated. I started by building the existing version which went fine. After this, I grabbed the latest code snapshot and noticed that a fix needed in the old version of this package is no longer needed. In the older version of this package there were missing DTD files that are needed. I verified that the new snapshot did in fact have these files. When building I found that this went relatively smoothly and was able to build using mock and koji without major issues. As you will notice in my screenshot, I have an i386 version of the package as well as a noarch version. This is because the Fedora repository version is built with GCJ and not Sun’s Javac. This is done because two of Fedora’s primary support platforms do not have a Just-In-Time compiler. PowerPC and PowerPC64 both rely on the (very) slow Hotspot interpreter when running Java bytecode.

Next Steps

These packages will be submitted for inclusion to the Fedora project using the standard methods. I have learned a lot about Java packaging by doing these packages and feel that packaging dependencies for JBoss will teach me a lot of the lessons I need to learn to package the main application server. Below is a run of rpm -qip for my package which gives the basic metadata for these packages.

During the Fedora 10 release party, I was lucky enough to speak with Matt from JBoss. He told me that Redhat has an internal effort and is going to let me know what the status is of that. It turns out that JBoss has a very strange build system from my understanding (using three separate tools!). Once my dependencies are met, it would be good to package individual modules of JBoss before moving on to the full App Server package.

As far as my project goes, I spoke with Chris last week to set goals for my 0.3 release. He and I decided that a reasonable goal is to package 4 dependencies, one which fedora has an older version, one where there is a newer one, one which is only in JPackage and one which isn’t in Fedora or JPackage. I will likely need the exam week to work on my project.