Giving up on creating a port of OpenNMS

After 5 years of going back & forth, I’ve decided to give up on trying to complete the OpenNMS ports for FreeBSD and dropped maintainership of the Java dependencies in the ports tree (net/jicmp, net/jicmp6, databases/jrrd, databases/iplike)

There are some issues which are show stoppers that need addressing upstream

  1. Separation of configuration & user data from the location of application binaries, Initially I began patching the source to look for files in a different location to the default so that things would integrate with the user land correctly but it soon became apparent that the patching would be a nightmare to maintain on an ongoing basis due to the number of patches required per configuration file. It was clear that things would need to be dealt with at the source rather than patched post release, a long running discussion with developers, bug reports raised, some (minor) patches submitted, 4+ years on, still ignored due to a lack of interest.
  2. Dynamically generated filenames, inherited from Google Web Toolkit, every build attempt generates new filename which make packing impossible.
    Update OpenNMS developer Benjamin Reed points to a possible fix
  3. Unreliable build process, maven fails between 2 to 3 times minimum which would cause lots of false alarms in an automated build environment e.g. the freebsd build cluster.
    This is somewhat of an improvement from a few years back where it would not be possible to build because repositories were not available for a day or two.

As it stands, the port is a shell which make it easy to install OpenNMS on FreeBSD but has major issues when it comes to upgrades or uninstallation. It’s best install dependencies from ports & install OpenNMS manually.