|
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:
The current SNAP installation directory structure is based on the NetBeans platform.
# | Title | User Story | Importance | Notes |
---|---|---|---|---|
1 | Executable script | Shell and batch scripts are needed to execute gpf | Must Have | 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 | |||
3 | Collect native libraries | |||
4 | Execute activators on start | |||
5 | Multiple running instances | As we don't use NetBeans runtime for running gpt this is probably no problem. | ||
-c /path/to/special.properties
In the installation directory in the bin folder shall be an executable script named gpt.bat/.sh
. The script will start the runtime as before in BEAM. The runtime needs to lookup the jar files from the multiple modules
directories of the multiple clusters. We have two options here:
BootstrapClasspath (Module Runtime)
By using this classpath we could have separate classpaths for each module which would allow to have 3rd-party library in different versions, if implemented. But parsing of dependencies need to be done on manifest.mf
or module.xml
needs to be reactivated.
The following two issue need to be implemented in both cases:
java.library.path
. They are located in <cluster>/modules/lib. The same mechanism as NetBeans to resolve native libs should be used.On Calvalus gpt is not used. Instead GPF is called directly via API. The executable code (the modules) is provided on Calvalus as bundle. When a process is invoked on Calvalus all jar files in this bundle are put on the classpath via the Java VM -cp option. Native libraries are also provided with this bundle and it is ensured by the system operator/bundle provider that the libraries are properly provided to the invoked process. Properties are set given in the bundle descriptor or are provided with the processing request. What needs to be done on Calvalus before the SNAP engine is used, is that the start methods of the modules are invoked and afterwards the stop methods.
Below is a list of questions to be addressed as a result of this requirements document:
Question | Outcome |
---|---|
(e.g. How we make users more aware of this feature?) | Communicate the decision reached |