Page Comparison

Goals

• Engine shall be runnable standalone (without NetBeans)
• Starting and stopping of the standalone runtime shall be possible
  • Activator must be called on start and stop
• Harmonise user.home cache temp location between desktop and engine
• The Graph Processing Tool must be invokable from the command line.
• reuse existing ceres runtime framework
• the java.library.path must be set
• The engine shall be able to start other main classes like PConvertMain.
  • The main class to be invoked must be given as parameter

...

Users wish to use SNAP libraries or to develop their own tools based on SNAP libraries. Very often, such applications are run in headless environments, without a GUI such as ist is the case for batch-mode processing or processing services. In BEAM and in the Sentinel Toolboxes 1.x it was relatively simple to collect a classpath from all the libraries because all binaries have been included in the lib and modules sub-directories. Since SNAP 2, libraries are distributed in the installation directory according to NetBeans clusters. It is no longer straight forward for users to collect required libraries form a NetBeans installation structure. 

Also, the NetBeans platform allows only for a single module runtime instantiation which means, only a single NetBeans application can be launched from an installation directory (unless we invoke it with different user directories). But in a headless environment we don't need and want the NetBeans module runtime at all. The goal is therefore to allow users use the SNAP Engine modules and their extension modules independently of NetBeans.

Even the SNAP Engine has at least two applications of itself:

1. The Graph Processing Tool, GPT, a command-line tool
2. The Product Converter, PConvert, another command-line tool 

Background and strategic fit

The current SNAP installation directory structure is based on the NetBeans platform. 

Assumptions

Requirements

...