Building a fuse-message-broker rpm

Summary

This document outlines the process to build a fuse-message-broker rpm. It also shows how we apply patches on top of a particular broker configuration

Starting Point

The starting point for the build process is a binary tarball produced by FUSE, which resides on their maven repository. We track whatever whatever is the Production release. If we have a particular problem we can either apply a patch against this specific release or roll ahead to a snapshot build.

Version numbers

There is some confusion in FUSE and Apache versioning - FUSE released a 5.3.0 before the offical Apache release. This thread describes the current state of branches in the FUSE repo as of Feb 2010.

Preparing a release

The pieces required to build are in Manchester SVN : https://www.sysadmin.hep.ac.uk/svn/grid-monitoring/trunk/msg/fuse-rpm. This consists of a standard 'koji-style' Makefile which consists of a sources target. It points directly at the fusesource.com maven repo to download a tarball. Whenever you wish to up the release you need to update the contents of the sources file with the name and md5sum of the new tarball. Both these can be found by browsing fusesource.com repository.

If you build a SNAPSHOT release from a nightly build of a particular branch, then the release number should be set to the date the branch was built e.g. 103026. This would give a full rpm version - 5.3.1_fuse_00_SNAPSHOT-100326.el5.

# Makefile
TGZREPO=http://repo.fusesource.com/maven2/org/apache/activemq/apache-activemq/5.3.0-fuse-01-00

SOURCEFILES := $(shell cat sources 2>/dev/null | awk '{ print $$2 }')
sources: $(SOURCEFILES) 

$(SOURCEFILES):
        @echo "Downloading $(TGZREPO)/$@..."
        curl -H Pragma -O -R -S --fail --show-error $(TGZREPO)/$@

clean:
        @for F in $(SOURCEFILES) ; do \
          rm -f $$F ; \
        done

The specfile does the moving around of the files. In general we try and provide as close a copy of the original tarball in the rpm. There are a few things to note:

• We deploy all the files into /usr/share/activemq/ and mimic the default packaging where the broker puts the log and data files in the same structure as the code. The log and data files are actually put in the correct places (/var/log/activemq and /var/cache/activemq) with symlinks into /usr/share/activemq.
• To make it compatible with rpm naming, we change the version by replacing '-' with '_' e.g. 5.3.0-fuse-01-00 becomes 5.3.0_fuse_01_00. The original package name (apache-activemq) and version are available in the specfile as variables - respectively %{fusename} and %{fuseversion}
• We bundle our own init.d script which supports /etc/sysconfig/activemq to configure the location of the config files we wish to use.
• We create a client rpm which only contains the activemq-all-%{fuseversion}.jar in the standard java jar location
• We only deploy the binary Java Service Wrapper for whatever architecture (i386 or x86_64) that we're building the rpm for.

• We deploy custom patch jar files where we have extra patches to fix specific bugs. See below under Patching.

Building

Building is then done via koji in the standard way. We currently only build the broker for SL5. The reason that we build from a binary, while not particularly good, is that we don't support maven projects in koji right now (for reasons of dependency handling).

> koji build dist-centos5 svn+http://www.sysadmin.hep.ac.uk/svn/grid-monitoring/trunk/msg/fuse-rpm#3234
> koji tag-pkg dist-centos5-testing fuse-message-broker-5.3.0_fuse_01_00-1.el5

Patching

There are two types of 'patching':

1. Adding new features into activemq which we have developed. This is done via another rpm oat-activemq-patches. This contains the actual sources which are used to build the jars.
2. Modifying existing classes in the FUSE release. this is done by rebuilding specific rpms from the FUSE release of ActivemMQ.

The fact that we do a 'binary build' in koji also has implications for patching. Currently the building of the patch jars needs to be done by hand. All patches that we apply should have already been submitted upstream to Apache ActiveMQ project via their JIRA. Below we outline the steps to patch the fuse-message-broker rpm.

1. Checkout a copy of the appropriate tag from the FUSE SVN repository - you need a fusesource account for this.
2. Apply your patch to this tag
3. Build the whole project using maven (i.e. mvn package). You should do at least one build where you run the entire test suite (takes a long time !). To run without tests you can do mvn -Dmaven.test.skip=true package.
4. Take the specific jars which have been changed and check them into fuse-rpm directory - they should contain the version numbers of the fuse-message-broker release, just like the original rpm.
5. Update the patches/README file with the references to the activemq bugs which have the patches.
6. checkin the patches themselves into the patches directory
7. Update the fuse-message-broker.spec to patch the appropriate files in %{fusehome}/lib