STATUS: Proposal accepted
Problem description
The Sling Project archetype (and also the Slingstart Archetype, Sling Launchpad Standalone Archetype ) embed a fixed version of the Sling Starter/Launchpad. This is problematic for Sling users since the Sling Starter is not meant to be a production-ready application base:
- there is no enforcement of backwards compatibility
- there are not enough mechanisms to override the Starter application ( e.g. uninstall certain bundles, change the access control setup )
With enough effort these can achieved, but it is unlikely that we will be able to invest enough in the Sling Starter.
Furthermore, Sling-based applications do not embed the Sling Starter either:
- https://github.com/apache/sling-org-apache-sling-app-cms/tree/master/feature/src/main/features
- https://github.com/redhataccess/pantheon/tree/master/sling-org-apache-sling-karaf-features/src/main/feature
- https://github.com/data-team-uhn/cards/tree/dev/distribution/src/main/features
- https://github.com/ist-dresden/composum-launch/tree/master/feature/sling-starter-copy/src/main/features
Proposal
Instead of importing the Sling Starter using the Feature Model, the Sling Project Archetype can instead copy the exact feature file definitions from the Sling Starter, with an additional feature file where the user's application is defined, e.g. the bundles and content packages defined in the project itself.
The embedding of the feature files from Sling Starter can be done at build time using Maven references or by copying the files from a Git tag.
Implementation
Tracked at SLING-11922 - Getting issue details... STATUS