Collector Development Guide
The Build Process
Let's take a brief timeout to discuss the build process for Sentinel Collectors. If you've made it this far, it should be clear how to edit the release.js file to add additional parsing, but it might not be clear how your code actually ends up in a running Collector. To understand how this works, we need to go over the build process.
Running a Build
This is a bit of a review, but here's how to run a Collector build:
- Launch Eclipse and ensure you are using the Sentinel perspective.
- Expand the collectors section in the Sentinel SDK pane at left.
- Expand the Vendor and Product directories for the Collector you are interested in building.
- Right-click on the Collector version you wish to build (probably 2011.1).
- Select either Create Production Build or Create Development Build, as appropriate.
- An Ant console window should pop up showing you the log output of the build process (watch this for errors).
What the Build Does
So what is this build actually doing? What follows is a fairly complete, but not exhaustive explanation:
A development build:
- Cleans out the build area
- Copies in selected files from your development directory
- Copies in selected files from the template
- Also copies any library files specified in your files.include file
- Creates a package.xml file that describes the plug-in, pulling information from:
- The directory structure
- Your plugin.properties file
- Your connectionMethods.xml file
- Your deviceSupport.xml file
- Any parameters that you have defined
- ZIPs everything up into a plug-in package.
The production build does the same as the development build, then adds:
- Merges the device-specific information from your documentation into a template, then exports PDFs
- Adds information (size, checksum) about the plug-in files to the package.xml file
- Creates a Collector Pack by merging any custom controls you have defined with a template Pack, then removing any controls that you have excluded via the controls.exclude file
- Generates an MD5 hash file for download verification.
Customizing the Build
There are a few aspects of the build that you can control using some profile properties, and it is also possible to make more extensive changes using an SDK overlay mechanism. We'll document the properties here.
Profile-based build properties are stored in your profile (
$HOMEDIR/.netiq/pluginsdk/dev.properties) and include:
- This property defines the name of the author that is injected into each plug-in's package.xml built from this SDK. Here at NetIQ we use 'NetIQ Engineering', but you should set this to something to represent yourself.
- This property provides an alternative location where builds are created. The default is
SDKROOT/content/build, but you can set this to any directory.
- This defines the actual version of the SDK that you will build against. Ordinarily this is set
SDKROOT/current/sdk, which represents the latest SDK available, but you can repoint this to an older, more stable version if desired. Use the Switch SDK Ant task to change this (more on this later).
- The property provides an alternative SDK local extension. By default this points to
SDKROOT/current/sdk-local; if you need to customize major aspects of the SDK, you can make a copy of the default SDK and modify as needed.
Collector Development Guide
- Getting Started
- Initial Build
- Plug-in Contents
- Data Parsing
- Build Process
- Event Construction
- Connector Interaction
- Common Code
- Additional Information