Hi, On Fri, 2020-10-16 at 15:30 -0400, Daniel Klco wrote: > 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 website to produce artifacts would create a Maven project, ready to import into an IDE and start work with. If I understand your proposal, the Docker launcher approach would allow users to create an application to launch but not a project. Is that correct? > > 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. I've seen this idea floated around a couple of times. I think it has merit and to make it happen we need to a) make sure the features are flexible enough and b) it does not burden development too much. Regarding a), I think the of current starter has two main parts: - a list of the latest bundles that work together - a set of configurations + repoinit statements that are working and reasonable I think mostly everyone will want to use the latest modules that we validated, and overrrides are easily done using the feature model [0]. If we split the features to individual modules and advertise them as reusable then we also need to ensure that various configurations and repoinit statements can be overridden/removed. For instance, some installations may wish to give fewer permissions to the sling-package- install user [1] or adjust the service unavailable filter [2]. Another idea would be that each feature would publish two artifacts: - bundle list - default configs And a project can either accept the default configs completely or create their own. Feature grouping is something that we should also take into account. If a user wants to remove the web console completely, or the OSGi installer, how easy would that be? It's actually b) that I think needs the most discussion. How often would you see the features themselves released? If we plan to release them with each bundle that's an extra burden for the one doing the releases. But if we don't release them every time then the Starter would drift or get back to using snapshot versions. I think both of these should be avoided. Thanks, Robert [0]: https://github.com/apache/sling-org-apache-sling-feature/blob/master/docs/features.md#prototype [1]: https://github.com/apache/sling-org-apache-sling-starter/blob/5e8f7bb00afbab065c307bd68ee80fbedb00d76a/src/main/features/base-repoinit.txt#L52-L58 [2]: https://github.com/apache/sling-org-apache-sling-starter/blob/5e8f7bb00afbab065c307bd68ee80fbedb00d76a/src/main/features/healthcheck.json#L80-L99 > > Thoughts? > > > > > > On Thu, Oct 15, 2020 at 12:14 PM Robert Munteanu <[email protected]> > 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 > > > >
