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
