Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

We have restructured the SDK to let you create modules with ease.  This new format  reduces configuration, simplifies building, eases dependency management and makes it easier to set up the development environment of your choosing.

In past versions of the SDK, developers were provided a sizable zip file, complete with jars, javadocs, this guide, and some third party dependencies.  Builds were run using Ant, through the included Build directory.  This all made sense when the original SDK was conceived – Ant was stable, Maven just stabilizing and Gradle wasn't even born.  However, we're not in 

With repositories like Maven Central,and dependency management through Maven and Ivy, Java has moved to the cloud.  With the new Ignition 7.7 SDK, we have taken the same approach to provideyou with simple dependency management, modern build tools, and open source example modules on our Github page.  

SDK Structure

The Ignition SDK consists of a collection of APIs that are hosted through a Maven repository.

The JAR files that define the actual API. Outlined below.


The JavaDocs technical documentation compiled off of the API.
Example projects that illustrate different types of modules.


The API consists of the following JAR files that will need to be referenced as dependencies by your projects.


Core API and classes exposed by the Ignition platform

client-api.jar Needed for "client" scope
designer-api.jar Needed for "designer" scope
gateway-api.jar Needed for "gateway" scope

Vision APIs exposed by the Vision Module

  • vis-client-api.jar
  • vis-designer-api.jar
  • vis-common.jar 
    • Common files for both the client and designer.  


Drivers APIs exposed by the OPC-UA module

  • driver-api.jar 
    • Used to create new drivers for the OPC-UA module.

Alarming APIs exposed by the Alarm-Notification





Software Design Tip

Maximize your code reuse, modularity and maintainability by using common directories for source that is used across multiple scopes/apis.

  • No labels