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 < > > > > romb...@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 > >
