I think there's still value in producing a runnable JAR, even if under the hood it's using the Feature Model, especially for people just getting into Sling.
For the dynamic option, what if instead of creating some sort of website to produce artifacts, we had a Docker image that would take one or more Maven coordinates as parameters, download the features and then use the Sling Feature Launcher to launch an instance using the features. We could create a webpage / webform to allow users to search for valid coordinates and show them the command to execute. The other thing that I'd relate to this is that the Starter with a single project wrapping multiple features is not ideal. Instead, every feature should be a separate project (or at least be able to be released separately) with a sane set of configurations so that a consumer could import an updated version of the feature when the underlying bundle is updated rather than having to wait until Starter is released or fork and sync like I'm doing with the CMS. This does mean some additional release work where we'd have to update the feature models and release along with bundle updates, but it would make it easier on downstream projects to use features of Sling in a granular way. In this model, both the Docker Image and Sling Starter are consumers of these base features. Thoughts? On Thu, Oct 15, 2020 at 12:14 PM Robert Munteanu <romb...@apache.org> wrote: > On Fri, 2020-10-02 at 07:36 +0000, Stefan Seifert wrote: > > the discussion then did go further whether we should rethink the way > > of doing sling releases in the future: > > > > - should we still perform releases this way? > > > > - JavaDoc generation should be decoupled from our annual releases, > > should be done automatically and updated for each module release > > > > - probably we could just do with "snapshot releases" / "nightly > > builds" - and vote from time to time to make an official release out > > of it? > > > > - Should we replace the Sling Starter release with a "release > > generator" web page that allows the user to download a project? For > > instance: > > > > Scripting: [ ] jsp, [ ] htl, [ ] freemarker, [ ] thymeleaf > > > > Discovery: [ ] standalone, [ ] oak > > > > Persistence: [ ] Tar, [ ] MongoDB > > > > Launcher: [ ] feature model, [ ] karaf > > > > - We have two launcher alternatives - Feature Launcher, Kickstarter. > > We should only keep one. > > To give a bit more background, we were discussing whether having a > Sling Starter release actually brings value to our users except for > "This is how a Sling application should look like". > > The Starter is obviously very useful for us as developers to integrate > our changes and test them in a sane environment, manually and/or > automatically. > > For the users, my assumption (which is of course disprovable) is that > they are building their own application taking the starter as an > initial point. And our releases happen so rarely I doubt anyone is > waiting for the next Starter release to upgrade. > > I also suspect that the Starter has great documentation value, as it > shows what bundle versions work together, what configurations are > required, expected repository structure and service users, etc. > > So one of the ideas floated around was to have a generator webpage that > builds a sample Sling project based on user input. This project will be > based on the Sling Starter configuration from git and copy instead of > reference the feature files. > > This has the potential of removing a lot of release engineering effort. > There are two things which are not entirely clear to me right now: > > 1. What do we lose when switching to this model? For instance, users > wouldn't be able to download Sling and start playing around with it. > > 2. Is this OK from a legal point of view? I don't think we are dancing > around the ASF release policy, but if anyone has any concerns it'd be > good to discuss them. > > Comments/questions welcome. > > Thanks, > Robert > >
