Packaging software is a necessary evil, and for enterprise software RPMs even more so, but you might as well find out how to manage it when you really want to just work all from your Mac.
The quick and easy solution would be to leverage the rpm (and rpmbuild) tool can be installed via homebrew and the rpm-maven-plugin. Unfortunately, this is in no way recommended as a way to build packages for production. Futher, I’ve found that any package I built could not be installed on a CentOS box, even though it was built with no specific architecture; when the RPM is packaged, the source operating system was imprinted on the RPM, preventing it from being installed.
I still recommend using the rpm-maven-plugin - its pretty convenient and works mostly as expected, nothing crazy to point out here (beyond a decently documented maven component!).
To build packages for production, you really need to build the software in an environment matching that on which you will run. This ensures correctly library linking and native bits. During my time at Salesforce, we were actually building on a completely different OS than we were running and had only gotten lucky that the same C-library was used on both the build and production operating systems (specifically, we were building snappy). We only found the issue when we upgraded production and suddenly our packages no longer worked as expected! Lesson learned.
Fortunately, there is a solution for this, and its come quite a long way in the last few years: Vagrant!
Originally, I wasn’t even going to post this because it was so very simple to spin up a VM - a mere two hours from conception to working instance. However, there were some subtleties that are worth pointing out.
My target OS is Centos 6.5.3 - the latest commonly available CentOS release - as I’m trying to build for RHEL, but don’t want to spend the money (at least right now) on a RHEL subscription.
The build I was working with required a few elements:
rpmbuild is a standard yum package, but from there the components become increasingly more complicated: maven needs to downloaded from a release tarball, java8 requires a special cookie on download and protobuf requires a full build from source (as of writing, only 2.3.1 is readily available).
As its just me, I’ve set to estabilish an accessible maven repository, so my custom forks are instead leveraged from the local .m2 repository. As such, I’ve also linked my local .m2 repository to the VM’s path. The upside to this is that we don’t need to rebuild or redownload any jars when we want to build our project, instead relying on the ones stored on the host OS (it saves space, time and bandwidth). Remember, this is fine because compiled java jars are OS agnostic, so we can leverage the same jars regardless of whence they originated.
Here are the scripts I used:
and the provisioning script:
Like this sort of stuff? Consider subscribing to the RSS feed.
blog comments powered by Disqus