...
The experimental Crankstart launcher was created in early 2014 to support some Sling operations / cluster prototypes: Artyom Stetsenko's prototype and Bertrand's Docker/Sling cluster playground. It was modified in 2015 to support the Sling Provisioning Model and is used in integration tests for the ./contrib/commons/mom/jobs/it module.
Terminology
A Sling Instance Config (SIC) fully describes the configuration of a Sling instance, including all bundles, run modes, OSGi configurations, OSGi framework properties, repoinit statements etc.
Sling NG Launcher Design Goals
...
- Launch a single, optionally immutable (in terms of configits SIC) Sling instance from a SIC.
- Define the SIC in a diff-friendly and structured text format that's also human-friendly, including comments. YAML comes to mind.
- Refer to artifacts using Maven coordinates - these can always be converted to other types of URIs as needed.
- Provide a way to specify digests and/or signatures for those artifacts, to validate them before use.
- Include OSGi configurations in the SIC so that everything is defined there.Include and OSGi framework properties (including framework version selection) in the SIC so that everything is defined there
- Allow for merging two or more SICs with well defined rules, optionally using signatures or digests to validate the included SICs
- Allow for run mode dependent settings including artifacts, OSGi configurations and OSGi framework properties
- Provide a way to supply configuration values from the environment, for example to connect the Sling instance to a Mongo storage server via an URL supplied at runtime.
Nice to have
Some of these need a refined specification to decide whether they are actually needed.
- Use a minimal launcher that "never" needs to change, like Crankstart does.
- Maybe combine declarative instructions (lists of bundles for example) with procedural statements ("start framework") for example to allow for optimized and deterministic startup scenarios.
- Allow for dynamic extensions of the startup languagemechanism, like Crankstart does.
- If using a runnable jar, allow for influencing the launcher setup (run modes probably) by renaming the runnable jar. That's a useful way of producing runnable jars with multiple modes that are very easy to repurpose, by just renaming.
- Maybe allow for pre-assembling the instance for faster startup, like downloading dependencies in advance and embedding in the launcher jar file or in a "sidecar" jar that can be accessed locally.
Open Questions
- Do we need or want run modes in the SIC? We might also create different deployments by combining a set of base SICs in different ways.
- Runtime or build time assembly? Crankstart gets and assembles artifacts at startup time, launchpad at build time.