This page is meant to discuss the requirements and design of a new Sling launcher.
It was created in September 2014 to help build consensus about such a launcher.
Current status
The current launchpad/runnable jar approach does not seem ideal for modern operations where one wants to drive the creation and configuration of Sling instances from (structured) text files that can be managed in Git or other source code control systems, for programmable infrastructure (aka devops).
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.
Carsten has started work on a Slingstart launcher which consists of a Maven plugin and, for now, a set of example definition files.
Terminology
A Sling Instance Config (SIC) fully describes the configuration of a Sling instance, including all bundles, run modes, OSGi configurations, OSGi framework properties, etc.
Sling NG Launcher Design Goals
Must have
- Launch a single, immutable (in terms of config) 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 (like bundles, but can be anything) via URIs to keep the distributable SIC small. The launcher can retrieve those artifacts at startup time, or, optionally embed them in its runnable jar to build standalone launchers like the current launchpad does.
- 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.
- Combine declarative instructions (lists of bundles for example) with procedural statements ("start framework") for example to allow for optimized and deterministic startup scenarios.
- Provide a way to supply configuration values from the environment, for example to connect the Sling instance to a Mongo server via an URL supplied at runtime.
Nice to have
- Use a minimal launcher that "never" needs to change, like Crankstart does.
- Allow for including partial SICs into the main one, with signatures or digests to validate them.
- Allow for dynamic extensions of the startup language, like Crankstart does.
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.