How do I customize the openNMS project

I am planning to use opennms as the backbone and create a custom nms. I want to do the following

  1. Customize the UI
  2. NETCONF support
  3. Specific UI for my EMS

Can anyone help me with an idea on development approach ?
I followed the developer guide and cloned opennms into my intellij workspace from git.
After changes I should run the compile and assemble scripts?
How can I deploy this as a docker container?

These question were discussed in our chat room.
Unfortunately people don’t use the reply function, so I hope those links cover the complete conversation.

https://chat.opennms.com/opennms/pl/8g7wj1ad1fgdmrufzqqprgtchy

https://chat.opennms.com/opennms/pl/bhp188osufbfzqg8yeo3q19bue

1 Like

Reply I got in the chat forum was to take help from OpenNMS group about customization approach

Depending on what you’re doing, this is a vast topic with a lot going on, so it’s hard to give a good answer without a lot of detail about what you’re wanting to do. That said, I would like to give a more generic response to the question of what you need to think about when customizing OpenNMS code for your own needs.

In general, step 1 is to fork the OpenNMS git repository, and start making the changes you want to see. Hand-editing already built artifacts after the fact is not a good long-term strategy for maintaining a set of changes against OpenNMS. Despite being a massive codebase, things tend to move fast and we are still doing a lot of architectural changes to refactor our (very old) codebase to be more nimble and modern, so you will find things change out from under you a lot if you’re not starting from the source.

For many historical reasons, the OpenNMS codebase has a lot of strange corners, so don’t be afraid to pop in to the OpenNMS Development chat channel and ask specifics. It can be daunting getting to know our code but there are plenty of folks that can help you out.

If you make changes that fix bugs or add new features, please consider sending us a pull requests with your changes (including relevant unit/integration/smoke tests!) and not just leaving them in your fork. It makes it easier for everyone involved for a number of reasons, not just selfishly from the OpenNMS project’s POV:

  1. If you have good unit/integration/smoke tests we will catch issues when architectural changes are made to OpenNMS that would affect your new feature. We will do the work of maintaining it for you (although obviously, we would love your coordination/help on things that you would obviously be the Subject Matter Expert for). We run continuous integration on every build and find problems early when there is good code coverage.
  2. You don’t have to worry about dealing with licensing issues and making sure you make available your customized changes, since the AGPL obligates you to do so even if people are just using your modified OpenNMS as a “user”. Since it will be in the official upstream OpenNMS, it’s covered.
  3. It means less changes in your fork, which makes it easier to track upstream overall, and you will want to track upstream, since we fix bugs and security issues all the time. Not to mention new features…

Also a thing to note, if you are looking to productize OpenNMS, the name “OpenNMS” and the OpenNMS logo are trademarked and copyrighted, respectively. If you are planning on distributing or posting modified versions of OpenNMS as your own product you will need to change all the branding, just like CentOS does with Red Hat Enterprise Linux.

If you have any doubts or questions at all about how your use of the OpenNMS code base is impacted by the AGPLv3 license or by OpenNMS copyright or trademarks, you should consult a lawyer.

*takes off “community answer” hat and puts on The OpenNMS Group hat*

Finally, you are not in any way obligated to do so, but The OpenNMS Group offers an agreement called Powered By OpenNMS that offers non-GPL licensing as well as support for folks who wish to embed or customize OpenNMS for their own environment. Depending on your needs, you may want to give us a call and see if we can help you accomplish what you’re trying to do rather than going it alone. OpenNMS is big, old, and powerful and we have years of institutional knowledge about how to get the most out of the code and the config.

But in the end OpenNMS is open source and we believe strongly in that. There is absolutely nothing wrong with doing it yourself as long as you adhere to the licensing.

3 Likes

When I fork the source code I see many module folders. Compile and assemble takes a lot of time. In pom.xml it says old structure and new structure. opennms-webapp comes inside old-structure.
I need to use the webapp with basic features like provisioning and discovery. How can I customize it to use only minimal modules ? Commenting out the modules in pom.xml gives me errors

Do you need to permanently turn off features? Or are you just trying to do a minimal build to be able to test out changes in something specific (like opennms-webapp)? If the latter, you can do:

./compile.pl --projects org.opennms:opennms-webapp --also-make install

This tells it to read the entire tree of projects (to determine dependencies), but only build the opennms-webapp project, and then “also make” anything it depends on.

I’ll often do this while working on a particular bit of code. Then I can just copy the jar out of target/ and stick it in my already-built OpenNMS tree and restart to test.

1 Like

Trying to turn off the features , atleast till the first phase of my development. For now ur suggestion will help… thank you :slight_smile:

Also in pom.xml opennms-webapp module is mentioned as old-structure why is it so ?
What does the core module do ? If we need to use opennms web ui we should be having opennms-webapp module ryt ?

Because we stopped making new opennms-<something> in the top level, and now put things in features/, core/, etc.

“core” is for things that are a core part of launching OpenNMS, or for libraries that are used all over the OpenNMS codebase. Ideally it should stay small.

“features” is for the actual features of OpenNMS – event management, polling, etc.

“integrations” was meant for things that are like features, but considered less necessary or more niche or optional. The line has become a bit blurry there though.

1 Like

But webapp is still opennms-webapp ryt?

Yes, athough other code ends up into the “real” webapp as well… The final webapp is built in the opennms-assemblies/webapp-full project, which combines a bunch of dependencies. It also uses a custom maven plugin (opennms-warmerge-plugin) to create the final web.xml from tokens defined in the web.xml files of those dependent projects.

Sorry, but I dint get this right. Whats “real” webapp here ? When I was doing ui changes I was doing it in opennms-webapp folder and doing a compile, and assemble. Isn’t it the right place to do ? Also I observed that even if I comment out the opennms-webapp module in pom.xml and do a compile and assembly , I am able to access the webapp in 8980 port. What am I missing here?

The “real” webapp is the webapp generated by the assembly in opennms-assemblies/webapp-full – that’s what ends up in $OPENNMS_HOME/jetty-webapps/opennms – it is a combination of multiple maven projects into one mega-webapp (of which the opennms-webapp project is the largest part). If you only disable opennms-webapp at the top level, the assembly is just grabbing an old copy of it out of maven.