Hi, good point, makes sense. We'll update the document
Thanks Carsten Ioan Eugen Stan wrote > Hi, > > Thank you both for the clarification. I think it is a reasonable approach. > > It's always best to validate specs with one or more implementations. > > Then I propose that in the interest of greater adoption, maybe a name > change is in order. > > Something that says: we install osgi packages and we are used by Sling > instead of having Sling in the name and inducing the idea of being Sling > specific or worst, Sling only. > > Thank you, > > On 21.02.2018 12:59, Carsten Ziegeler wrote: >> Hi, >> >> thanks! One major point of the feature model is to separate between the >> model and how it is used later on. All current existing approaches mix >> these two things in most cases. >> >> There is a lot of overlap with the Karaf feature model, but the idea is >> to get a common model that works for everyone and as David pointed out >> potentially creating an OSGi spec out of this. So the model should work >> for Karaf users, for people creating sub systems etc. >> >> In fact, the prototype we have in our whiteboard creates a Karaf kar >> file out of a feature which can then easily be used within Karaf. But >> that's just one way doing it >> >> Regards >> >> Carsten >> >> >> Ioan Eugen Stan wrote >>> Hi, >>> >>> I've looked on the specification and I've noticed that it also overlaps >>> with the Karaf Feature functionality. >>> >>> Is there any relation between the two? Is there collaboration between >>> the projects? >>> >>> As a user/consumer of technology I enjoy when technologies are >>> compatible and the tooling support is great. >>> >>> I believe collaboration in this area is beneficial. I would like to be >>> able to provision Sling features in Karaf and Karaf features in Sling >>> with ease. >>> >>> If you put the spec side by side they share a LOT of things, but there >>> are also some minor differences, like file format. Karaf uses XML which >>> has much better tooling support IMO, but this is a persistence format >>> and can be easily changed. >>> >>> >>> p.s. I like the spec, I imagine it took quite some time to write. Kudos ! >>> >>> Regards, >>> >>> [1] https://karaf.apache.org/manual/latest/provisioning >>> >>> >>> >>> On 21.02.2018 09:10, Carsten Ziegeler wrote: >>>> Thanks David >>>> >>>> We're neither 100% clear on the requirements nor on the structure, >>>> meaning we don't know how many and what modules this will be. As we're >>>> following the one module per git repo rule, it's currently impossible to >>>> create the correct git repositories. And I guess it doesn't make sense >>>> to rename them or remove them every now and then. >>>> >>>> As the collaboration with the whiteboard is the same as with separate >>>> modules, I don't think there is anything wrong with having this in the >>>> whiteboard for now. Moving it out now creates more problems than it solves. >>>> >>>> Regards >>>> >>>> Carsten >>>> >>>> >>>> David Bosschaert wrote >>>>> Hi all, >>>>> >>>>> Over the recent past some additions have been made to the requirements of >>>>> the Sling Feature Model. The updated requirements can be found here: >>>>> https://github.com/apache/sling-whiteboard/blob/master/featuremodel/readme.md >>>>> >>>>> Any additional requirements, let us know! >>>>> >>>>> I'm hoping to start contributing to the implementation of some of these in >>>>> the near term and was wondering - is there a reason why the feature model >>>>> still in the sling-whiteboard? Or would it make sense to put it in its own >>>>> Sling git repo or repos? >>>>> >>>>> Best regards, >>>>> >>>>> David >>>>> >>> > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
