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 >
