Target release 2.0 Epic Link to related JIRA epic or feature Document status Document owner Marco Peters Designer Former user (Deleted), Marco Peters Developers Former user (Deleted), Marco Peters QA Olga Faber (Unlicensed)

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

Why are you doing this? How does this relate to your overall product strategy?

Assumptions

• List the assumptions you have such as user, technical or other business assumptions. (e.g. users will primarily access this feature from a tablet).

Requirements

User Interaction and Design

Loading of Properties

1. Properties shall be loaded from the following places by default
   
   1. <SNAP_HOME>/etc/snap.properties
   2. <SNAP_USER_DIR>/etc/snap.properties
   Properties given in a file of SNAP_USER_DIR will overwrite those in SNAP_HOME.
2. 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
3. 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:

1. 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?

2. 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:

1. 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.
2. 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:

Not Doing

• List the features discussed which are out of scope or might be revisited in a later release.