...
| # | 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 | 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 running instances | As we don't use NetBeans runtime for running gpt this is probably no problemtool 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
...