SnmpAsset Adapter has dependency on Trapd

Description

The SnmpAssetAdapter uses the SyntaxToEvent class located in the trapd package. We should either move this class or break the dependency. Based on the lack of JavaDoc of the SyntaxToEvent class, it's not easily understandable what the purpose of the class or any of its methods provide.

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Alejandro Galue June 2, 2011 at 2:13 PM

A fix has been pushed to 1.10 in commit 970574c7b80fc87c672f39250c0782e92157e2b4

Alejandro Galue June 1, 2011 at 5:55 PM

That class is used (at least on Trapd), to proper create event parameters based on SNMP values. The main usage of this class is for properly decoding MAC Address and other MIB Variables (I think Seth did the change).

This class requires access to "org.opennms.core.snmp.api" (SnmpValue) and "opennms-model" (Parm/Value for Event).

As "opennms-model" depends on "snmp-dependencies", and "snmp-dependencies" depends on "org.opennms.core.snmp.api", SyntaxToEvent could be moved to opennms-model.

As "opennms-snmp-asset-provisioning-adapter" depends on "opennms-model", no changes are required (just remove the dependency with "opennms-services".

Based on the analysis, I made the changes, and this is what I did:

1. Merge the content of org.opennms.netmgt.trapd.EventConstants into org.opennms.netmgt.EventConstants (pretty straightforward).
2. Remove org.opennms.netmgt.trapd.EventConstants, and update all dependent classes to point to org.opennms.netmgt.EventConstants.
3. Move SyntaxToEvent and SyntaxToEventTest to opennms-model, and update all dependent classes.
4. Remove the POM dependency to opennms-services from "opennms-snmp-asset-provisioning-adapter"

Everything looks good (at least from eclipse point of view). I'm recompiling everything just to be sure that I'm not breaking something.

Make sense?

Alejandro.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

PagerDuty

Created February 23, 2011 at 9:13 AM
Updated January 27, 2017 at 4:21 PM
Resolved June 2, 2011 at 2:13 PM