You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2020/07/03 10:39:37 UTC
Re: kickstart-maven-plugin vs feature-launcher-maven-plugin (was:
[VOTE] Release Apache Sling Feature Launcher Maven Plugin 0.1.0)
Hi Andy,
(please read the following noting that I fully agree that we should not
introduce technical debt).
On Tue, 2020-06-30 at 11:21 -0700, Andreas Schaefer wrote:
> Hi Robert
>
> > On Jun 30, 2020, at 5:41 AM, Robert Munteanu <ro...@apache.org>
> > wrote:
> >
> > Hi Andy,
> >
> > I started a discussion at [1] regarding why I think a new plugin is
> > preferrable, even though we have the slingfeature and kickstart
> > plugins.
> >
> > I believe that the kickstart tooling is 'batteries-included' and
> > suitable for Sling applications, while the feature-launcher plugin
> > is
> > usable also for non-Sling applications based on the feature model.
> > Kickstart makes some assumptions, such as:
>
> Initially that was the plane but due to the way Feature Model and the
> Feature Launcher work. The Kickstart does use the Sling Feature Model
> or Feature Archives but neither is included but rather downloads and
> uses them.
Ack
>
> > - the application exposes an HTTP endpoint (and can have a context
> > path
> > , but configured using the Felix HTTP service)
> > - the application has runmodes
> > - the application exposes a control port
>
> The previous Sling Starter Maven Plugin did as well.
Ack. And I'm not saying that this is a bad thing. Sling apps will need
the extra features, but other apps won't .
I have developed applications that are based on the feature model but
not on Sling. In the provisioning model world we did not have this
distinction. With the feature model being generic and under discussion
in the OSGi expert groups ( see [2] ) I think having a generic Maven
launcher makes sense, as opposed to one geared towards Sling
applications.
>
> > - the application uses the org.apache.sling.commons.log bundle
>
> That can be changed. I think this is here because of the old Sling
> Starter Maven Plugin.
I'm not saying that it should. If you take away all the custom
configurations from the kickstart plug-in you end up with a generic
feature launcher. Is that a goal for the kickstart plugin?
>
> > I think this is fine for 'downstream' applications building on
> > Sling,
> > but not true for pure feature model applications. Hence the idea of
> > having separate launchers.
>
> The Kickstart Maven Plugin is pretty light weight but it has a
> dependency on the Sling Kickstart Project which contains the FAR file
> and hence is pretty big. I am not sure if it is possible to make this
> dependency dynamic so that it is only obtained when needed.
Right, this comes back to the idea of having a Sling launcher vs a
feature launcher. The kickstart is a Sling launcher that uses the
feature model because Sling uses the feature model. The feature model
launcher's job is to launch feature model applications.
>
> > There may be an opportunity for the kickstart plugin to inherit
> > some of
> > the low-level plumbing from the feature launcher plugin, to make
> > sure
> > we have a consistent lauch experience. But that can come later.
>
> I doubt that as the Kickstart Maven Plugin is using the Kickstart
> Project and only provides the Maven facade. I think here we have a
> duplication of features that I think is unnecessary and can lead to a
> technical debt but then the entire Feature Model is in flux and so I
> do not have all the answers.
Then we can set up the plumbing in the kickstart project. I think it
would not be terribly hard to have the common bits in there and then
expose it in separate ways in the kickstart and feature-launcher
plugins.
> The thing I am mostly concern is the confusion it may create for the
> user as the Feature Model is difficult due to the lack of examples
> and End-to-End projects.
Yes, I agree that there is a lack of documentation for the feature
model in general. But I'm not sure if that should stop us from
improving our tooling :-)
Thanks,
Robert
[2]: https://blog.osgi.org/2019/07/new-osgi-work-features.html
Re: kickstart-maven-plugin vs feature-launcher-maven-plugin (was:
[VOTE] Release Apache Sling Feature Launcher Maven Plugin 0.1.0)
Posted by Radu Cotescu <ra...@apache.org>.
Hi Robert and Andy,
I think Robert’s arguments make a lot of sense. We need a very lightweight
plugin for starting apps based on the feature model. Kickstart’s goals seem
to be a bit more involved with the Sling world, but the feature model has
the potential to break the Sling barriers and having this
“do-one-thing-only-and-do-it-well” approach is something that I appreciate
a lot.
One app that Robert and I worked on is the Apache Sling Committers CLI.
It’s the tool we use for managing the mundane release tasks and, although
it has Sling in its name, it’s not a Sling web application. A plugin like
the one Robert suggested would help with use cases like this one.
I’m not picking sides in any way here, btw. I’m just saying that there’s
room for both plugins, since their goals are quite different.
Cheers,
Radu
On Fri, 10 Jul 2020 at 14:31, Robert Munteanu <ro...@apache.org> wrote:
> Hi,
>
> I have filed https://issues.apache.org/jira/browse/SLING-9581 as a
> follow-up task for reducing duplication in the next releases.
>
> IMO we should continue with the vote unless someone considers this a
> blocker and votes -1.
>
> Thanks,
> Robert
>
> On Wed, 2020-07-08 at 09:27 +0300, Robert Munteanu wrote:
> > Hi Andy,
> >
> > Did you get a chance to review the previous message? I'd like to get
> > to
> > a conclusion related to this particular vote.
> >
> > Thanks,
> > Robert
> >
> > On Fri, 2020-07-03 at 12:39 +0200, Robert Munteanu wrote:
> > > Hi Andy,
> > >
> > > (please read the following noting that I fully agree that we should
> > > not
> > > introduce technical debt).
> > >
> > > On Tue, 2020-06-30 at 11:21 -0700, Andreas Schaefer wrote:
> > > > Hi Robert
> > > >
> > > > > On Jun 30, 2020, at 5:41 AM, Robert Munteanu <
> > > > > rombert@apache.org>
> > > > > wrote:
> > > > >
> > > > > Hi Andy,
> > > > >
> > > > > I started a discussion at [1] regarding why I think a new
> > > > > plugin
> > > > > is
> > > > > preferrable, even though we have the slingfeature and kickstart
> > > > > plugins.
> > > > >
> > > > > I believe that the kickstart tooling is 'batteries-included'
> > > > > and
> > > > > suitable for Sling applications, while the feature-launcher
> > > > > plugin
> > > > > is
> > > > > usable also for non-Sling applications based on the feature
> > > > > model.
> > > > > Kickstart makes some assumptions, such as:
> > > >
> > > > Initially that was the plane but due to the way Feature Model and
> > > > the
> > > > Feature Launcher work. The Kickstart does use the Sling Feature
> > > > Model
> > > > or Feature Archives but neither is included but rather downloads
> > > > and
> > > > uses them.
> > >
> > > Ack
> > >
> > > > > - the application exposes an HTTP endpoint (and can have a
> > > > > context
> > > > > path
> > > > > , but configured using the Felix HTTP service)
> > > > > - the application has runmodes
> > > > > - the application exposes a control port
> > > >
> > > > The previous Sling Starter Maven Plugin did as well.
> > >
> > > Ack. And I'm not saying that this is a bad thing. Sling apps will
> > > need
> > > the extra features, but other apps won't .
> > >
> > > I have developed applications that are based on the feature model
> > > but
> > > not on Sling. In the provisioning model world we did not have this
> > > distinction. With the feature model being generic and under
> > > discussion
> > > in the OSGi expert groups ( see [2] ) I think having a generic
> > > Maven
> > > launcher makes sense, as opposed to one geared towards Sling
> > > applications.
> > > > > - the application uses the org.apache.sling.commons.log bundle
> > > >
> > > > That can be changed. I think this is here because of the old
> > > > Sling
> > > > Starter Maven Plugin.
> > >
> > > I'm not saying that it should. If you take away all the custom
> > > configurations from the kickstart plug-in you end up with a generic
> > > feature launcher. Is that a goal for the kickstart plugin?
> > >
> > > > > I think this is fine for 'downstream' applications building on
> > > > > Sling,
> > > > > but not true for pure feature model applications. Hence the
> > > > > idea
> > > > > of
> > > > > having separate launchers.
> > > >
> > > > The Kickstart Maven Plugin is pretty light weight but it has a
> > > > dependency on the Sling Kickstart Project which contains the FAR
> > > > file
> > > > and hence is pretty big. I am not sure if it is possible to make
> > > > this
> > > > dependency dynamic so that it is only obtained when needed.
> > >
> > > Right, this comes back to the idea of having a Sling launcher vs a
> > > feature launcher. The kickstart is a Sling launcher that uses the
> > > feature model because Sling uses the feature model. The feature
> > > model
> > > launcher's job is to launch feature model applications.
> > >
> > > > > There may be an opportunity for the kickstart plugin to inherit
> > > > > some of
> > > > > the low-level plumbing from the feature launcher plugin, to
> > > > > make
> > > > > sure
> > > > > we have a consistent lauch experience. But that can come later.
> > > >
> > > > I doubt that as the Kickstart Maven Plugin is using the Kickstart
> > > > Project and only provides the Maven facade. I think here we have
> > > > a
> > > > duplication of features that I think is unnecessary and can lead
> > > > to
> > > > a
> > > > technical debt but then the entire Feature Model is in flux and
> > > > so
> > > > I
> > > > do not have all the answers.
> > >
> > > Then we can set up the plumbing in the kickstart project. I think
> > > it
> > > would not be terribly hard to have the common bits in there and
> > > then
> > > expose it in separate ways in the kickstart and feature-launcher
> > > plugins.
> > >
> > > > The thing I am mostly concern is the confusion it may create for
> > > > the
> > > > user as the Feature Model is difficult due to the lack of
> > > > examples
> > > > and End-to-End projects.
> > >
> > > Yes, I agree that there is a lack of documentation for the feature
> > > model in general. But I'm not sure if that should stop us from
> > > improving our tooling :-)
> > >
> > > Thanks,
> > > Robert
> > >
> > > [2]: https://blog.osgi.org/2019/07/new-osgi-work-features.html
> > >
>
>
Re: kickstart-maven-plugin vs feature-launcher-maven-plugin (was:
[VOTE] Release Apache Sling Feature Launcher Maven Plugin 0.1.0)
Posted by Robert Munteanu <ro...@apache.org>.
Hi,
I have filed https://issues.apache.org/jira/browse/SLING-9581 as a
follow-up task for reducing duplication in the next releases.
IMO we should continue with the vote unless someone considers this a
blocker and votes -1.
Thanks,
Robert
On Wed, 2020-07-08 at 09:27 +0300, Robert Munteanu wrote:
> Hi Andy,
>
> Did you get a chance to review the previous message? I'd like to get
> to
> a conclusion related to this particular vote.
>
> Thanks,
> Robert
>
> On Fri, 2020-07-03 at 12:39 +0200, Robert Munteanu wrote:
> > Hi Andy,
> >
> > (please read the following noting that I fully agree that we should
> > not
> > introduce technical debt).
> >
> > On Tue, 2020-06-30 at 11:21 -0700, Andreas Schaefer wrote:
> > > Hi Robert
> > >
> > > > On Jun 30, 2020, at 5:41 AM, Robert Munteanu <
> > > > rombert@apache.org>
> > > > wrote:
> > > >
> > > > Hi Andy,
> > > >
> > > > I started a discussion at [1] regarding why I think a new
> > > > plugin
> > > > is
> > > > preferrable, even though we have the slingfeature and kickstart
> > > > plugins.
> > > >
> > > > I believe that the kickstart tooling is 'batteries-included'
> > > > and
> > > > suitable for Sling applications, while the feature-launcher
> > > > plugin
> > > > is
> > > > usable also for non-Sling applications based on the feature
> > > > model.
> > > > Kickstart makes some assumptions, such as:
> > >
> > > Initially that was the plane but due to the way Feature Model and
> > > the
> > > Feature Launcher work. The Kickstart does use the Sling Feature
> > > Model
> > > or Feature Archives but neither is included but rather downloads
> > > and
> > > uses them.
> >
> > Ack
> >
> > > > - the application exposes an HTTP endpoint (and can have a
> > > > context
> > > > path
> > > > , but configured using the Felix HTTP service)
> > > > - the application has runmodes
> > > > - the application exposes a control port
> > >
> > > The previous Sling Starter Maven Plugin did as well.
> >
> > Ack. And I'm not saying that this is a bad thing. Sling apps will
> > need
> > the extra features, but other apps won't .
> >
> > I have developed applications that are based on the feature model
> > but
> > not on Sling. In the provisioning model world we did not have this
> > distinction. With the feature model being generic and under
> > discussion
> > in the OSGi expert groups ( see [2] ) I think having a generic
> > Maven
> > launcher makes sense, as opposed to one geared towards Sling
> > applications.
> > > > - the application uses the org.apache.sling.commons.log bundle
> > >
> > > That can be changed. I think this is here because of the old
> > > Sling
> > > Starter Maven Plugin.
> >
> > I'm not saying that it should. If you take away all the custom
> > configurations from the kickstart plug-in you end up with a generic
> > feature launcher. Is that a goal for the kickstart plugin?
> >
> > > > I think this is fine for 'downstream' applications building on
> > > > Sling,
> > > > but not true for pure feature model applications. Hence the
> > > > idea
> > > > of
> > > > having separate launchers.
> > >
> > > The Kickstart Maven Plugin is pretty light weight but it has a
> > > dependency on the Sling Kickstart Project which contains the FAR
> > > file
> > > and hence is pretty big. I am not sure if it is possible to make
> > > this
> > > dependency dynamic so that it is only obtained when needed.
> >
> > Right, this comes back to the idea of having a Sling launcher vs a
> > feature launcher. The kickstart is a Sling launcher that uses the
> > feature model because Sling uses the feature model. The feature
> > model
> > launcher's job is to launch feature model applications.
> >
> > > > There may be an opportunity for the kickstart plugin to inherit
> > > > some of
> > > > the low-level plumbing from the feature launcher plugin, to
> > > > make
> > > > sure
> > > > we have a consistent lauch experience. But that can come later.
> > >
> > > I doubt that as the Kickstart Maven Plugin is using the Kickstart
> > > Project and only provides the Maven facade. I think here we have
> > > a
> > > duplication of features that I think is unnecessary and can lead
> > > to
> > > a
> > > technical debt but then the entire Feature Model is in flux and
> > > so
> > > I
> > > do not have all the answers.
> >
> > Then we can set up the plumbing in the kickstart project. I think
> > it
> > would not be terribly hard to have the common bits in there and
> > then
> > expose it in separate ways in the kickstart and feature-launcher
> > plugins.
> >
> > > The thing I am mostly concern is the confusion it may create for
> > > the
> > > user as the Feature Model is difficult due to the lack of
> > > examples
> > > and End-to-End projects.
> >
> > Yes, I agree that there is a lack of documentation for the feature
> > model in general. But I'm not sure if that should stop us from
> > improving our tooling :-)
> >
> > Thanks,
> > Robert
> >
> > [2]: https://blog.osgi.org/2019/07/new-osgi-work-features.html
> >
Re: kickstart-maven-plugin vs feature-launcher-maven-plugin (was:
[VOTE] Release Apache Sling Feature Launcher Maven Plugin 0.1.0)
Posted by Robert Munteanu <ro...@apache.org>.
Hi Andy,
Did you get a chance to review the previous message? I'd like to get to
a conclusion related to this particular vote.
Thanks,
Robert
On Fri, 2020-07-03 at 12:39 +0200, Robert Munteanu wrote:
> Hi Andy,
>
> (please read the following noting that I fully agree that we should
> not
> introduce technical debt).
>
> On Tue, 2020-06-30 at 11:21 -0700, Andreas Schaefer wrote:
> > Hi Robert
> >
> > > On Jun 30, 2020, at 5:41 AM, Robert Munteanu <ro...@apache.org>
> > > wrote:
> > >
> > > Hi Andy,
> > >
> > > I started a discussion at [1] regarding why I think a new plugin
> > > is
> > > preferrable, even though we have the slingfeature and kickstart
> > > plugins.
> > >
> > > I believe that the kickstart tooling is 'batteries-included' and
> > > suitable for Sling applications, while the feature-launcher
> > > plugin
> > > is
> > > usable also for non-Sling applications based on the feature
> > > model.
> > > Kickstart makes some assumptions, such as:
> >
> > Initially that was the plane but due to the way Feature Model and
> > the
> > Feature Launcher work. The Kickstart does use the Sling Feature
> > Model
> > or Feature Archives but neither is included but rather downloads
> > and
> > uses them.
>
> Ack
>
> > > - the application exposes an HTTP endpoint (and can have a
> > > context
> > > path
> > > , but configured using the Felix HTTP service)
> > > - the application has runmodes
> > > - the application exposes a control port
> >
> > The previous Sling Starter Maven Plugin did as well.
>
> Ack. And I'm not saying that this is a bad thing. Sling apps will
> need
> the extra features, but other apps won't .
>
> I have developed applications that are based on the feature model but
> not on Sling. In the provisioning model world we did not have this
> distinction. With the feature model being generic and under
> discussion
> in the OSGi expert groups ( see [2] ) I think having a generic Maven
> launcher makes sense, as opposed to one geared towards Sling
> applications.
> > > - the application uses the org.apache.sling.commons.log bundle
> >
> > That can be changed. I think this is here because of the old Sling
> > Starter Maven Plugin.
>
> I'm not saying that it should. If you take away all the custom
> configurations from the kickstart plug-in you end up with a generic
> feature launcher. Is that a goal for the kickstart plugin?
>
> > > I think this is fine for 'downstream' applications building on
> > > Sling,
> > > but not true for pure feature model applications. Hence the idea
> > > of
> > > having separate launchers.
> >
> > The Kickstart Maven Plugin is pretty light weight but it has a
> > dependency on the Sling Kickstart Project which contains the FAR
> > file
> > and hence is pretty big. I am not sure if it is possible to make
> > this
> > dependency dynamic so that it is only obtained when needed.
>
> Right, this comes back to the idea of having a Sling launcher vs a
> feature launcher. The kickstart is a Sling launcher that uses the
> feature model because Sling uses the feature model. The feature model
> launcher's job is to launch feature model applications.
>
> > > There may be an opportunity for the kickstart plugin to inherit
> > > some of
> > > the low-level plumbing from the feature launcher plugin, to make
> > > sure
> > > we have a consistent lauch experience. But that can come later.
> >
> > I doubt that as the Kickstart Maven Plugin is using the Kickstart
> > Project and only provides the Maven facade. I think here we have a
> > duplication of features that I think is unnecessary and can lead to
> > a
> > technical debt but then the entire Feature Model is in flux and so
> > I
> > do not have all the answers.
>
> Then we can set up the plumbing in the kickstart project. I think it
> would not be terribly hard to have the common bits in there and then
> expose it in separate ways in the kickstart and feature-launcher
> plugins.
>
> > The thing I am mostly concern is the confusion it may create for
> > the
> > user as the Feature Model is difficult due to the lack of examples
> > and End-to-End projects.
>
> Yes, I agree that there is a lack of documentation for the feature
> model in general. But I'm not sure if that should stop us from
> improving our tooling :-)
>
> Thanks,
> Robert
>
> [2]: https://blog.osgi.org/2019/07/new-osgi-work-features.html
>