| Page Properties | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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
...
An essential SNAP requirement is allowing users to develop their own applications based on SNAP Java libraries. Very often, such applications are run in headless environments, without a GUI such as it is the case for batch-mode processing or web 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 it is invoked with a different user directory - TBC). But in a headless environment users don't need and don't want the NetBeans module runtime at all. The ultimate goal is therefore allowing users to use the SNAP Engine modules and their extension modules independently of NetBeans and of other unwanted (GUI) modules. Along with that, it should be possible to run any number of non-NetBeans applications on a single SNAP 2 installation directory.
Background and strategic fit
The STEP Cloud Exploitation Platform, CEP, is a component that requires a headless use of the SNAP Java libraries. For example, it should be possible to directly use SNAP Java libraries for the implementation of Hadoop MapReduce jobs.
The SNAP Engine itself has at least two applications:
- The Graph Processing Tool, GPT, a command-line tool
- The Product Converter, PConvert, another command-line tool
Assumptions
Requirements
| # | Title | User Story | Importance | Notes | |||||
|---|---|---|---|---|---|---|---|---|---|
| 1 | Executable script | Shell and batch scripts are needed to execute gpf | These scripts shall be placed in the bin folder of the installation directory. Must be done by our own installer. | 2 | Collect modules on classpath | Multiple apps | Users shall be able to write their own applications using Engine libraries (JARs). For Java implementations, provide a Launcher which will invoke the client's main() method in the context of the dynamically created classpath from configured Engine JARs. For Python implementations, provide an Engine API which can be called via the Python-Java bridge in order to run SNAP API in the ontext. | ||
| 2 | Dynamic classpath | The Engine shall be able to dynamically create a client class path to be used by client code. The Engine API shall allow for accessing it. | |||||||
| 3 | Collect native libraries | The Engine shall be able to dynamically detect any directories containing supplemental native libraries (based on JNI) and modify "java.library.path" accordingly. | |||||||
| 4 | |||||||||
| 4 | Execute activators on start | ||||||||
| 5 | Multiple running instances | As we don't use NetBeans runtime for running gpt this is probably no problem. | |||||||
| Module lifecycle | (Engine) modules shall offer services that are informed on Engine start/stop so that they can perform any module lifecycle actions (similar to OSGi Activator class, NetBeans Installer class). | ||||||||
| 5 | Multiple tool instances | It shall be possible to have multiple instances of Engine tools running at the same time, e.g. 5 GPT invocations running in parallel. | |||||||
| 6 | OSGi | Any Engine API design shall be compatible with a later migration of the Engine modules to OSGi | Desired |
User Interaction and Design
...
- Properties shall be loaded from the following places by default
- <SNAP_HOME>/etc/snap<cluster>.properties
- <SNAP_USER_DIR>/etc/snap<cluster>.properties
- Properties file given on command line
On the command line it shall be possible to specify a properties file. Properties given here overwrite properties loaded from SNAP_USER_DIR or SNAP_HOME.
The command line option could be
-c /path/to/special.properties - Properties given as VM parameters
These properties shall have the highest priority and overwrite any other property loaded.
...