So What is SliMpoGrine?

SliMpoGrine is trying to make a case for developing Sling-based web-applications. At first was the silly idea of combining two CMS into one docker image. Out of the initial project archetype fell an example app. Making that a CSS Zen Garden is a cheap trick to get it visually appealing too, something the Sling project is traditionally bad at :-)

Also some lessons can be taken about creating a Sling application from scatch: Importing existing markup as Sightly script (aka HTL), split it up into includes and components, copy over the CSS, separate markup from text while understanding that it's still all content from Sling's perspective. There is just one "business" Sling-Model, the CSS-Picker.

SliMpoGrine Participants

The participating CMS's are Composum's Pages+Assets and Peregrine-CMS. The idea is to use them and write how we got here. Despite Sling being around for a long time, it's use within the open-source realm is limited. Developing on top of it is arguably "Fun and Simple", hard parts are start and finish.

Starting means leaning about the stack: Why do I want my web-content saved in a JCR tree-structure, how everything comes together in OSGi, setup your own project, deploy content-packages, user-manager ...

Finishing means how to deploy Sling as a docker container on a low-cost server, including a webserver in front that does some caching. So the idea is to provide tips+tricks, the paths '/content/slimpogrine' (what you're reading here), '/content/sites/slimpo' and '/content/sligrine' are synched back into packages and part of a self-explaining docker-image. PRs welcomed.

SliMpoGrine Benefits

This is not software on it's own but a combination of open-source software using the OSGi Feature Maven Plugin. The Sling Starter already comes with applications on top, developed by IST, a Node-Browser (think crx/de), User- and Package-Manager. SliMpoGrine basically adds two CMS. Because you can.

SliMpoGrine Requirements

Required is a general interest in Java middle-ware. And some knowledge in AEM-development probably, at least till this documentation project has progressed. There are several approaches to achieve the same. The 'traditional' on-premise style of just starting the Apache Sling Docker Image and installing own code with the Package-Manager.

But in order to play around with the feature-model, the first approach was to fork the Sling-Starter and add stuff. But when looking at the archetype on how to create close-sourced apps on top, I figured out the starter project publishes a new artifact TYPE 'slingosgifeature' to maven-central. That can be imported into your own feature-model. So you have a starting point that actually boots and spins up a JCR-repository, OSGi container, Jetty and everything else. Likewise you could import the slingosgifeature of this silly project.

That's also not a sane idea, but it somehow shows the power behind the concept of feature-models. (Which are basically units of bundles+content-packages+configs+repoint-scripts, to be explained later in one of the CMS hopefully).

Another approach would be to use the Sling docker image as a base-layer in your own Dockerfile plus some maven magic or curl-commands to install own code on top. That is probably a reasonable approach - but not used here.

Space in CSS ran out. Inspired by the work of Dan Klco on Sling-CMS (another one!) and Robert Munteanu's Kubernetes deploment.