You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Stefan Seifert <ss...@pro-vision.de> on 2020/10/02 07:36:51 UTC
[roundtable] Sling 12 + future release process
what is currently missing for a release is finalizing conversion to feature model - using natively FM, still a couple of thinks that are not done - archetype, documentation, docker images - https://cwiki.apache.org/confluence/x/RBgRCQ
creating sling releases in the current approach takes a considerable amount of time and involves a lot of manual steps
we should not wait until more feature that are currently in progress are ready, would be nice to have out Sling 12 soon
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.
Re: [roundtable] Sling 12 + future release process
Posted by Robert Munteanu <ro...@apache.org>.
On Fri, 2020-10-02 at 07:36 +0000, Stefan Seifert wrote:
> we should not wait until more feature that are currently in progress
> are ready, would be nice to have out Sling 12 soon
+1
From my point of view we still have to finish the feature model
conversion [0]:
- docker support
- kickstart
- documentation
- archetypes
and make sure we don't ship with regressions:
- SLING-9825, SLING-9826 - JCR support regression, requires a new
oak.server release [1][2]
- SLING-9842 - sun.mic.Unsafe not available OOTB [3]
- SLING-9648 - error logged at startup, needs a settings bundle release
[4]
Are there any other items that are important to have in the next
Starter release?
Thanks,
Robert
[0]: https://cwiki.apache.org/confluence/display/SLING/Migrating+the+Sling+Starter+to+the+Feature+Model
[1]: https://issues.apache.org/jira/browse/SLING-9826
[2]: https://issues.apache.org/jira/browse/SLING-9825
[3]: https://issues.apache.org/jira/browse/SLING-9824
[4]: https://issues.apache.org/jira/browse/SLING-9648
Re: [roundtable] Sling 12 + future release process
Posted by Robert Munteanu <ro...@apache.org>.
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 <ro...@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
> >
> >
Re: [roundtable] Sling 12 + future release process
Posted by Daniel Klco <dk...@apache.org>.
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 <ro...@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
>
>
Re: [roundtable] Sling 12 + future release process
Posted by Robert Munteanu <ro...@apache.org>.
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