Independent features instead of a single project (was: Releasing Sling Starter 12)

[Robert Munteanu <ro...@apache.org>]

Hi Eric,

On Sat, 2022-02-12 at 11:27 -0800, Eric Norman wrote:
> Is there any interest in splitting the feature definitions from the
> starter
> project?
> 
> IMHO, it would be better if the starter was just referencing small
> features defined elsewhere and then each of those features could be
> released on its own schedule.

I know the answer may be obvious :-) but I'd still like to ask: why is
it better to have distinct projects per feature instead of a single
Starter project?

Thanks,
Robert

Re: Independent features instead of a single project (was: Releasing Sling Starter 12)

[Robert Munteanu <ro...@apache.org>]

Hi Eric,

On Fri, 2022-02-25 at 09:14 -0800, Eric Norman wrote:
> Hi Robert,
> 
> FWIW, we have the repository maintenance already as an example
> 
> 
> Yes, the maintenance feature is pretty close to what I was thinking
> of.
> However, the maintenance.json in the starter project currently has no
> customizations to the feature that it is wrapping.  I think it would
> be
> better to use a reference to the original feature via refsInclude as
> described at [3] rather than wrapping it.  There probably isn't much
> benefit to having two substantively identical feature definitions.
> 
> 3.
> https://github.com/apache/sling-slingfeature-maven-plugin#supported-goals
> 
> Sorry, I haven't had the free time to work on a more flushed out
> example,
> perhaps in the next few days.

There is no rush from my side since this will probably be part of Sling
13. I would like to make more frequent releases of the Starter, but
it's still probably be months until the next one.

Thanks,
Robert

> 
> Regards,
> - Eric
> 
> 
> On Fri, Feb 25, 2022 at 5:03 AM Robert Munteanu <ro...@apache.org>
> wrote:
> 
> > On Mon, 2022-02-21 at 11:47 +0100, Robert Munteanu wrote:
> > > On Mon, 2022-02-14 at 11:58 -0800, Eric Norman wrote:
> > > > > 
> > > > > why is it better to have distinct projects per feature
> > > > > instead of
> > > > > a
> > > > > single
> > > > > Starter project?
> > > > 
> > > > 
> > > > In my opinion, it would be better for a variety of reasons,
> > > > such
> > > > as;
> > > 
> > > (snip)
> > > 
> > > Yup, all good points. I think there are some downsides as well,
> > > but
> > > rather than trying to iron out every little detail, perhaps it
> > > would
> > > be
> > > worth making an experiment in the Sling whiteboard?
> > 
> > FWIW, we have the repository maintenance already as an example [1],
> > [2], but that's maybe too small a feature to consider it a 'real'
> > experiment.
> > 
> > Thanks,
> > Robert
> > 
> > [1]:
> > 
> > https://github.com/apache/sling-org-apache-sling-jcr-maintenance/tree/master/src/main/features
> > [2]:
> > 
> > https://github.com/apache/sling-org-apache-sling-starter/blob/master/src/main/features/maintenance.json
> > 

Re: Independent features instead of a single project (was: Releasing Sling Starter 12)

[Eric Norman <en...@apache.org>]

Hi Robert,

FWIW, we have the repository maintenance already as an example


Yes, the maintenance feature is pretty close to what I was thinking of.
However, the maintenance.json in the starter project currently has no
customizations to the feature that it is wrapping.  I think it would be
better to use a reference to the original feature via refsInclude as
described at [3] rather than wrapping it.  There probably isn't much
benefit to having two substantively identical feature definitions.

3. https://github.com/apache/sling-slingfeature-maven-plugin#supported-goals

Sorry, I haven't had the free time to work on a more flushed out example,
perhaps in the next few days.

Regards,
- Eric


On Fri, Feb 25, 2022 at 5:03 AM Robert Munteanu <ro...@apache.org> wrote:

> On Mon, 2022-02-21 at 11:47 +0100, Robert Munteanu wrote:
> > On Mon, 2022-02-14 at 11:58 -0800, Eric Norman wrote:
> > > >
> > > > why is it better to have distinct projects per feature instead of
> > > > a
> > > > single
> > > > Starter project?
> > >
> > >
> > > In my opinion, it would be better for a variety of reasons, such
> > > as;
> >
> > (snip)
> >
> > Yup, all good points. I think there are some downsides as well, but
> > rather than trying to iron out every little detail, perhaps it would
> > be
> > worth making an experiment in the Sling whiteboard?
>
> FWIW, we have the repository maintenance already as an example [1],
> [2], but that's maybe too small a feature to consider it a 'real'
> experiment.
>
> Thanks,
> Robert
>
> [1]:
>
> https://github.com/apache/sling-org-apache-sling-jcr-maintenance/tree/master/src/main/features
> [2]:
>
> https://github.com/apache/sling-org-apache-sling-starter/blob/master/src/main/features/maintenance.json
>

Re: Independent features instead of a single project (was: Releasing Sling Starter 12)

[Robert Munteanu <ro...@apache.org>]

On Mon, 2022-02-21 at 11:47 +0100, Robert Munteanu wrote:
> On Mon, 2022-02-14 at 11:58 -0800, Eric Norman wrote:
> > > 
> > > why is it better to have distinct projects per feature instead of
> > > a
> > > single
> > > Starter project?
> > 
> > 
> > In my opinion, it would be better for a variety of reasons, such
> > as;
> 
> (snip)
> 
> Yup, all good points. I think there are some downsides as well, but
> rather than trying to iron out every little detail, perhaps it would
> be
> worth making an experiment in the Sling whiteboard?

FWIW, we have the repository maintenance already as an example [1],
[2], but that's maybe too small a feature to consider it a 'real'
experiment.

Thanks,
Robert

[1]:
https://github.com/apache/sling-org-apache-sling-jcr-maintenance/tree/master/src/main/features
[2]:
https://github.com/apache/sling-org-apache-sling-starter/blob/master/src/main/features/maintenance.json

Re: Independent features instead of a single project (was: Releasing Sling Starter 12)

[Robert Munteanu <ro...@apache.org>]

On Mon, 2022-02-14 at 11:58 -0800, Eric Norman wrote:
> > 
> > why is it better to have distinct projects per feature instead of a
> > single
> > Starter project?
> 
> 
> In my opinion, it would be better for a variety of reasons, such as;

(snip)

Yup, all good points. I think there are some downsides as well, but
rather than trying to iron out every little detail, perhaps it would be
worth making an experiment in the Sling whiteboard?

I am thinking of taking one feature from the Sling Starter, copying it
out and testing out how reuse can look like in the Sling Starter and
the Sling CMS. I chose these two since they are quite close to the
Sling project, but anything else can work.

What I would really like to keep from the current Starter setup is to
only use releases and have quick/easy updates of bundles.

I think overall this is a good idea since I for one don't maintain any
'downstream' applications on top of Sling, and I suspect not many of us
do. Forcing us to think as 'consumers' of Sling can only be a good
thing.

Thanks,
Rober

Re: Independent features instead of a single project (was: Releasing Sling Starter 12)

[Eric Norman <en...@apache.org>]

>
> why is it better to have distinct projects per feature instead of a single
> Starter project?


In my opinion, it would be better for a variety of reasons, such as;

*1)* Modularity.  For example, if you need to upgrade to a new version of
oak or jetty to address some urgent problem, It would be easier to update,
test and release just the oak or jetty feature(s) rather than having to
stabilize the whole starter project in order to release the whole thing.


*2)* Release Frequency.  The starter project is released infrequently so
you may not want to wait.


*3)* Code Reuse.  For example, imagine you are starting a new project by
forking the starter project and then customizing it.  Now you must forever
keep checking the starter project changes for any differences that need to
be merged into your copy of the same.  If your fork is mostly the same as
the starter then there should be less differences to worry about if you
only have references to the common features.  Just look at how the similar
features from the org-apache-sling-app-cms and the starter projects have
deviated over time.


*4)* Separation of Responsibilities and Encouraging Feature Refinement.
When everything is inside the starter project there is less incentive to
keep clean separation of responsibilities within the features.  For
example, in the starter's scripting.json file, all the scripting languages
are defined in one feature instead of keeping the
freemarker/thymeleaf/jsp/esp/htl support separate from the core scripting
support.  So if you intend to only use htl scripting in your project you
can't just reference the scripting feature from the starter since you have
to do extra work to get rid of the freemarker/thymeleaf/esp/jsp bundles you
don't need in your distribution.  If the features were not inside the
starter then these types of things should be more visible.


*5)* Better Alignment with the Sling Karaf Features?  The sling karaf
features and the starter features are defined and grouped differently, so
perhaps there something that could be done to keep those in sync?



Now you may make the argument that you could accomplish many of the same
goals by having your custom projects just use references to the common
features that are released with the starter project.  Even in that scenario
there could be other reasons, such as:

*6)* Psychological.  The impression is that the starter is a demonstration,
so there may be a psychological reluctance to use those "demonstration"
features for production ready code.


That's all for now.  Does that make sense?

Regards,
-Eric

On Mon, Feb 14, 2022 at 7:57 AM Robert Munteanu <ro...@apache.org> wrote:

> Hi Eric,
>
> On Sat, 2022-02-12 at 11:27 -0800, Eric Norman wrote:
> > Is there any interest in splitting the feature definitions from the
> > starter
> > project?
> >
> > IMHO, it would be better if the starter was just referencing small
> > features defined elsewhere and then each of those features could be
> > released on its own schedule.
>
> I know the answer may be obvious :-) but I'd still like to ask: why is
> it better to have distinct projects per feature instead of a single
> Starter project?
>
> Thanks,
> Robert
>