This repo builds a Sling™ application-server with the OSGi Feature Model. It serves 3 example applications, a very basic one about templates plus two open-source CMS's. It comes as single micro-service (docker-image).
If docker is installed, easiest is to run the slimpogrine image from dockerhub.
docker run -p 8080:8080 -v slimpogrine-volume:/opt/sling/launcher orx0815dockerhub/slimpogrine
The admin's user:password is admin:admin. Some links on localhost:
Peregrine-CMS start / Peregrine sample-content
Composum start / Composum_pages sample-content
silly reverse-css-zengarden
OSGi Config-Manager ...
With a github account you can build and run the whole thing at gitpod.io. Just click here -> and it will start a developer environment in the browser.
Builds the project in the cloud somewhere and starts the server. Good way to confirm it not only "works on my machine".
Maven, Java 11 and 21
You need this peregrine-cms fork. (Only that has one content-package migrated to Jackrabbit FileVault Package Maven Plugin to make it work)
In the peregrine-cms folder run
mvn clean install
with Java 11 to have the required artefacts in your local .m2 repo.
In this directory here run
mvn clean install -Ddocker.skip=false
There is an example start-script
In the folder content-packages there are two sample-content packages:
- slimpo (for the Composum part)
- sligrine (for the Peregrine part)
They are both part of the initial content of the application server, meaning changes in content will be overriden when deployed again. So both have a content-download.sh to sync changes back into sources. Long term goal is to have more documentation here.
In the docker/webcache directory is the setup to launch an apache2 webserver for anonymous access of published web-content.
For testing on a local environment, add the following entries into your /etc/hosts file:
127.0.0.1 slimpo.motorbrot.local
127.0.0.1 sligrine.motorbrot.local
127.0.0.1 www.motorbrot.local
127.0.0.1 editor.motorbrot.local
There is an docker build_run script for that. When started, it should serve the silly reverse-css-zengarden here: http://www.motorbrot.local/
The current setup is for a single instance to provide an editor for logged-in users and also three websites served for everyone. The concept behind that is quite different though:
- The silly example just allows read-access for everyone.
- Composum's InPlace replication copies from /content path to /public when publishing.
- Peregrine is an SPA, it's publishing by writing json into local file-system.
${sling.home}/staticreplication is set in OSGi config LocalFileSystemReplicationService
In this case apache is not proxy'ing to Sling but serves json-files directly. Therefore, when starting slimpogrine the first time, it's necessary to click 'replicate Home' on this page in order to see it on sligrine.local. Also Sling and webcache have to run on the same docker-volume, so files written by Sling can be read by the webserver.
It should be possible to use Sling-Distribution to replicate content between author/publish instances in a cluster though.
Most of the magic is happening inside launcher/src/main/features.
That is where the sling-feature-model-plugin picks up the features to include.
At first I started off by forking the sling-starter in order to add an open-source CMS. Only later I found out about the new maven artefact-type 'slingosgifeature', which is basically json with maven-coordinates inside. It's published to maven-central by the sling-starter. We can use that in here to have something that actually boots and has a repository and so on. We can focus on our features to add on top.
Another different approach would have been to use a layered docker-image. Begin with the official apache-sling-starter image as base-layer and then install bundles and packages on top in our Dockerfile.
- Avoid hardcoded domains CONGA Sling Plugin maybe?
- How to deploy secrets like the openai/deepseek api-key ?
- SSL in front of the WebCache
- URL shortening reverse-outgoing-mapping not working yet for the domains
- GitOps, deploy with github actions
- why-use-a-composite-nodestore? Unsure, blue/green deployments maybe?