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 >>>> >>
signature.asc
Description: OpenPGP digital signature
