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
Background and strategic fit
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 | |||
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. | ||
User Interaction and Design
Loading of Properties
- Properties shall be loaded from the following places by default
- <SNAP_HOME>/etc/snap.properties
- <SNAP_USER_DIR>/etc/snap.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.
Run GPT from the Installation Directory
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:
- BruteForceClasspath
If we use the BruteForceClasspathFactory, which simply puts all jars on the class path, we will lose the flexibility that two modules can have the same dependency to a 3rd-party library but in different versions. This will not be possible.
Also there are to many modules on the classpath. Only engine modules need to be on the classpath. How to identify these modules? 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 onmanifest.mf
ormodule.xml
needs to be reactivated.
The following two issue need to be implemented in both cases:
- Native libraries need to be properly put on the
java.library.path
. They are located in <cluster>/modules/lib. The same mechanism as NetBeans to resolve native libs should be used. - A simple module lifecycle (start/stop). This needs to be compatible with NetBeans activation mechanisms.
Run GPF on Calvalus
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.
Questions
Below is a list of questions to be addressed as a result of this requirements document:
Question | Outcome |
---|---|