This article describes how to compile OpenNMS from source. If you have not set up your environment properly, please see here. Checkout the Code First of all, the code should be checked out. I usually do this in my ~/dev directory: git clone https://github.com/OpenNMS/opennms.git This will create an opennms directory in ~/dev/opennms. Next cd into it: cd opennms. Build from Source TL;DR Regular development time (.

Here we cover what is necessary to build OpenNMS from Source and afterwards start it locally on your Mac OS system. Compile Prerequisites In order to compile OpenNMS at least the following requirements should be met: The latest JDK 8 version should be installed makensis cloned github OpenNMS repository maven (optional) Run Prerequisites PostgreSQL server Jicmp, jicmp6 (both optional)

The other day I found my self in the lucky position to upgrade Karaf to a newer version. While doing that I also wrote something about our Http Bridge and why it was not be the best decision to integrate Karaf inside Jetty instead of the other way around. While implementing the Upgrade I asked my self how hard could it be to get some components of now running from within Jetty to running in Karaf.

Yesterday we encountered the issue, that the docker image build by Bamboo was not able to run on the agent itself, but locally did. As with docker this should not happen, so we have to investigate. It turns out, that some of our JAXB dependencies we put into ${karaf.home}/lib fail while loading. Simply removing them solved at least the Smoke Test failures. The last test failing, is probably a flapper.

Today I spend half of the day documenting the adventure of Updating Karaf to Version 4.2.2/4.2.3. Besides that a bunch of KarafTestCaseITs were still failing. As the issue is not solvable for now I decided to @Ignore them. Another issue is, that some of the system tests, e.g. HealthCheckIT fail on Bamboo, but pass locally on my system. Usually if something fails on Bamboo it can be reproduced locally and then fixed.

I thought with all the issues I already fixed, now everything should work again. NOPE. Bamboo is telling me that NxosTelemetryIT is no longer working. Okay, that is easy to reproduce with my system-test.sh script, inspired by some version from Jesse White. Running the script with the Bamboo URL to the build, e.g. /system-tests.sh https://bamboo.opennms.org/browse/OPENNMS-ONMS2773-14 as an argument will download the RPMs and build the same docker images as Bamboo would.

Until now we have fixed most of our issues. However one of the remaining issues were, that locally I was not able to login to the Karaf Shell for all the docker containers of Minion/Sentinel/OpenNMS. I thought that this was the same issue as reported by Bamboo. But it turned out, that it was a local Docker on Mac VM issue. Resetting the Docker VM solved at least that problem.

Yesterday we spend all day fiddling with our KarafTestCases and finally disabled them. Today I thought we were going to fix some of our failed Smoke Tests, but instead we are going to do something different. Looking at the docker containers build for our System Tests, I encountered the following exception in the karaf.log. Caused by: java.lang.IllegalArgumentException: Not supported: http://javax.xml.XMLConstants/property/accessExternalDTD Consulting the Oracle pointed me to a topic on the Karaf Mailing List.

Yesterday we fixed all Vaadin related issue and were very positive to have fixed a lot of issues and pushed our changes to Bamboo to see what actually all is broken. Integration Test wise, all Karaf related tests failed. I investigated the issue and long story short: Hacking the startup.properties in our KarafTestCase is no longer working, instead the library must be provided otherwise. Executing the tests don’t work anymore and result in a ClassNotFoundException, bundle wiring is no longer valid

Yesterday we learned, that Vaadin UIs are no longer working as they should. The sympthoms were that the first Vaadin UI you visited were always presented to you, no matter which one you accessed afterwards. My first finding was, that this is caused by the way Vaadin implements the @PreserveOnRefresh functionality. See NMS-10601 for more details. However after I addressed/fixed that issue, the problem was not. Debugging some more showed, that only one OsgiUIProvider was present in the VaadinSession, but multiple should be.