STATUS: Proposal accepted

Problem description

With the launchpad and provisioning model Sling Starter (or Launchpad) we always had a single deliverable - the executable jar. With the feature model this becomes more complicated, as we have multiple options for delivery and launch. We should make clear recommendations to our users, consumers of the Sling Starter, on how to obtain and launch it.


The Sling Starter serves two major purposes:

  1. Be an example for Sling users regarding how a Sling application can be structured
  2. Allow Sling users to quickly start up a Sling application and experiment with it

It is not an objective for the Sling Starter to be extended for production applications, as documented in the Sling Starter README.

Supported scenarios

The following scenarios are supported for discovering Sling functionality through the Sling Starter:

TS1: explore the Sling Starter Applications ( Welcome page, Composum, SlingShot)
TS2: run Sling Starter in various topologies - oak_tar, oak_mongo
TS3: access Sling Starter logs and runtime data
TS4: install, update, and uninstall bundles and content packages
TS5: perform various operations through the Web Console

Notably, altering the feature model and rebuilding the Sling Starter are not supported.

Available options

Feature Launcher

The Sling Feature Launcher launches feature model files ( defined as JSON ) or feature archives. It support various low-level options that control OSGi and Feature Model level configurations.

To launch the Sling Starter, the following requirements must be met:

  • A suitable version of the JRE is present locally
  • The feature launcher is present locally

Then, the user should execute the feature launcher and pass it the relevant arguments. These can be either feature files or feature models, and can either be present locally or accessed from a Maven repository.


$ java -jar -f
$ java -jar -f
$ java -jar -f

Kickstart Launcher

The Kickstart Launcher creates an executable jar that wraps a feature model archive. It exposes various high-level options controlling the behaviour of the Sling Starter.

To launch the Sling Starter, the following requirements must be met:

  • A suitable version of the JRE is present locally
  • The kickstart launcher is present locally


$ java -jar

Feature Launcher container

The Sling Feature Launcher is also able to produce a Docker image ( apache/sling-feature-launcher  ) during build time. This image can be used to launch feature-based applications. It is similar to the Feature Launcher  option, but does not require a locally installed JVM.

To launch the Sling Starter, the only requirement is a container engine.


$ docker run -e FEATURE_FILES="" --rm apache/sling-feature-launcher
$ podman run -e FEATURE_FILES="" --rm apache/sling-feature-launcher

Sling Starter container

We publish a Sling container image that exposes the full functionality of the Sling Starter at . This image can be launched via Docker (or another compatible runtime like Podman ). The configuration must be done using the environment variables accepted by the Sling Starter.

To launch the Sling Starter, the only requirement is a container engine.


$ docker run -e MONGODB_HOST=mongo apache/sling:12 oak_mongo
$ podman run -p 8080 apache/sling:12 oak_tar


JBang allows for running Java "scripts" which are real Java classes executed with a real JVM, without having to preinstall anything other than JBang.

Comments-based annotations in the scripts can be used to declare dependencies that are automatically downloaded, select a specific JVM etc.

Installing JBang is easy and does not require a JVM to be pre-installed. If one is available it will be used but that's not a requirement, and other JVM versions can be downloaded as needed.

Here are a few examples of how it could be used for the Sling starter.

These all use a JBang catalog from the sling-whiteboard repository, if we choose this option for the Sling Starter and other things we might create a specific sling-scripts repository for the catalogs and scripts.

To bypass the local JBang cache in case changes are made to the catalog or scripts, use the --fresh option.

Stub Sling Starter Script

The script simulates starting Sling.

Thanks to the jbang-catalog.json file added to the Sling Whiteboard repository it can be called as follows, based on the JBang naming conventions for catalogs:

$ jbang start@apache/sling-whiteboard -p 1234
This is just a stub for now but could start Apache Sling with the following arguments: [-p, 1234]

Parse a Repoinit Script

The script uses a //DEPS comment to load the repoinit parser as a dependency. It is also listed in the Sling Whiteboard JBang catalog so can be called as follows:

$ echo "create path /itworks" | jbang repoinitValidator@apache/sling-whiteboard
Repoinit parsing successful:
[CreatePath [itworks]]

Select a specific JVM version

The script uses a // JAVA comment to select a specific JVM version. It is also listed in the Sling Whiteboard JBang catalog so can be called as follows. Note that this downloads a JVM 13+ (and warns about that) if it's not available locally.

jbang jvmVersion@apache/sling-whiteboard


All the listed solutions fulfill the supported scenarios. To select a preferred solution, we should evaluate how easy they are to launch for our users.

SolutionLaunch requirementsLaunch complexity
Feature Launcher(red star) Supported version of Java, Feature Launcher downloaded locally(red star) Low-level, feature launcher flags
Kickstart Launcher(red star) Supported version of Java, Kickstart Launcher downloaded locally(green star) High-level, kickstart launcher flags
Feature Launcher Container(green star) Container runtime engine(red star) Low-level, feature launcher flags
Sling Starter Container(green star) Container runtime engine(green star) High-level, Sling Starter env vars and flags
JBang(green star) Just JBang(green star) Easy: simple command line with optional flags. Glue scripts do the rest.

Java vs Containers

The assumption that a container engine is a lower execution bar compared to a Java Runtime for our users need to be qualified.

The Sling Starter supports a range of Java versions, e.g. 8-17. We don't only ask our users to have a Java Runtime installed, we ask them to have a specific version. Each new Java version potentially breaks the Sling Starter in a way, and historically we have not released the Sling Starter frequently enough to

It is a reasonable assumption that users are more likely to have recent versions of Java installed, rather than old ones. So the problem here would be that we are asking users to install older Java runtime versions, which a) they may not want to do and b) reflects poorly on us.

As for the availability of container engines, there are two data points available:

  1. In the JRebel Java developer productivity report 2021 Virtualisation category, 57% of respondents use Docker, 42% Kubernetes (multiple selections possible). Only 4% do not use a virtualisation tool
  2. The StackOverflow developer survey 2021 reports that 55% of professional developers have done extensive development work with Docker. Additionally, Docker is on the second spot in the most loved/wanted technologies, behind Git.


Provide two recommended ways to launch the Sling Starter: the Sling Starter container, and a JBang catalog. Both of them will be presented together whenever one is documented. This will be reflected in the Sling Documentation and the Sling Starter README. Implementation will follow in SLING-9640 - Getting issue details... STATUS .

  • No labels