| Page Properties | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Goals
Users wish to use SNAP libraries or An essential SNAP requirement is allowing users to develop their own tools applications based on SNAP librariesJava libraries. Very often, such applications are run in headless environments, without a GUI such as ist 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 we invoke it is invoked with a different user directoriesdirectory - TBC). But in a headless environment we users don't need and don't want the NetBeans module runtime at all. The ultimate goal is therefore allowing users to allow users use the SNAP Engine modules and their extension modules independently of NetBeansand of other unwanted (GUI) modules. Even the SNAP Engine 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 of itself:
- The Graph Processing Tool, GPT, a command-line tool
- 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
| # | Title | User Story | ImportanceNotes | ||||||
|---|---|---|---|---|---|---|---|---|---|
| 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
...