Novell is now a part of OpenText

Collector Development Guide

BUILD PROCESS

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.

The Plug-in SDK uses Eclipse functionality to kick off builds, and under the hood uses a tool called Ant to script the actual build process. Ant is a bit like make in that it describes how a bunch of source files can be turned into an production component. In this case, Ant will merge the source files and various directives and properties that you have defined in the development directory with a bunch of template resources, and then give you a final ZIP file that can be imported directly into Sentinel. For Collector builds, there's no actual compilation occurring, and you can still look at the JavaScript source code in the debugger in the running Collector.

Running a Build

This is a bit of a review, but here's how to run a Collector build:

  1. Launch Eclipse and ensure you are using the Sentinel perspective.
  2. Expand the collectors section in the Sentinel SDK pane at left.
  3. Expand the Vendor and Product directories for the Collector you are interested in building.
  4. Right-click on the Collector version you wish to build (probably 2011.1).
  5. Select either Create Production Build or Create Development Build, as appropriate.
  6. 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
    Constructs a JAR that references the framework JARs plus any you have added
  • 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
  • Minifies the template JavaScript to reduce the size of the plug-in
  • 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:

author
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.
buildroot
This property provides an alternative location where builds are created. The default is SDKROOT/content/build, but you can set this to any directory.
sdkroot
This defines the actual version of the SDK that you will build against. Ordinarily this is set to 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).
sdklocalroot
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

Development Topics

© Copyright Micro Focus or one of its affiliates