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. > > - 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. > - 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 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. > > 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. 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. > > Hope that makes sense, > > Thanks, > Robert > > > [1]: > https://lists.apache.org/thread.html/r82f6d582137ae0de968ba3f8db0abaa7319f6595c7e48c393043034d%40%3Cdev.sling.apache.org%3E > > On Mon, 2020-06-29 at 10:44 -0700, Andreas Schaefer wrote: >> My question still is why is this necessary. The Sling Kickstart Maven >> Plugin does the same thing and if something is missing it can be >> added. >> Even though it is geared towards launching Sling it can launch any >> other Feature Model or Feature Archive (‘can’ here means that I can >> put that in place but might now work right now like that). >> >> Cheers - Andy >> >>> On Jun 29, 2020, at 9:22 AM, Robert Munteanu <romb...@apache.org> >>> wrote: >>> >>> Hi, >>> >>> We solved 1 issue in this release: >>> https://issues.apache.org/jira/browse/SLING/fixforversion/12348455 >>> >>> Staging repository: >>> https://repository.apache.org/content/repositories/orgapachesling-2291/ >>> >>> You can use this UNIX script to download the release and verify the >>> signatures: >>> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD >>> >>> Usage: >>> sh check_staged_release.sh 2291 /tmp/sling-staging >>> >>> Please vote to approve this release: >>> >>> [ ] +1 Approve the release >>> [ ] 0 Don't care >>> [ ] -1 Don't release, because ... >>> >>> This majority vote is open for at least 72 hours. >>> >>> Regards, >>> Robert Munteanu >
