Hi David I understand your points. And yes, I think you are right: it makes sense to have a impl at Felix. Other projects like Sling or Karaf have three options: don’t use the spec, have their own spec impl, leverage Felix impl.
I’m changing my vote to +1 about having an impl in Felix. Anyway I would be more than happy to work with you folks on the specs. Regards JB > Le 11 août 2021 à 11:34, David Bosschaert <[email protected]> a > écrit : > > Hi JB, > > The good news is that as of the beginning of this year, OSGi is now at > Eclipse [5]. The specification project is hosted at > https://github.com/osgi/osgi and the working group details are at [6]. > Anyone can join in the spec project calls (see the calendar at [7]), join > the mailing list [8] and provide PRs on the project - it just works as a > regular Eclipse opensource project. JB (and others) you can just join these > :) > > It's very common and actually really good if multiple technologies already > exist that relate to a spec. This is one of the reasons where a > specification makes a lot of sense. In the case of Features a number of > technologies already existed in this area, including Sling Features, Karaf > Features, Eclipse Features and others. > As Karl mentioned, hopefully these technologies will support OSGi Features > in the future. > > The implementation of the OSGi Features that I worked on is a very small > 'compatible' implementation. It doesn't have all the bells and whistles > that other implementations have. But it provides an implementation of the > API defined in the spec. In order for the OSGi spec at Eclipse to be > released there needs to be at least one Compatible Implementation. > > So in summary the benefits are: > * OSGi at Eclipse is open for all now > * The proposed implementation would allow the spec to be released - which > helps if other projects would like to support it too > * Having this implementation in Felix would avoid any confusion around > naming, which was flagged by the Sling community - as there would only be > one Features implementation at Felix. > > JB, all, I hope you see the benefits. > > Best regards, > > David > > [5] https://projects.eclipse.org/proposals/osgi-specification-project > [6] https://projects.eclipse.org/projects/technology.osgi > [7] > https://calendar.google.com/calendar/embed?src=c_fh3lhb5p0l29f6phu2ndifh4a4%40group.calendar.google.com&ctz=America%2FToronto > [8] https://accounts.eclipse.org/mailing-list/osgi-dev > > >> On Wed, 11 Aug 2021 at 10:08, Jean-Baptiste Onofré <[email protected]> wrote: >> >> I understand the purpose, however where I'm really concern is the fact >> that the OSGi Alliance is doing spec without considering existing >> implementations. >> >> I would love to have been involved in the features spec definition, but >> it's not possible as an individual, or as ASF member. >> >> Karaf features exist for 10+ years now, and I remember discussion with >> some OSGi people while ago saying "it's useless, it doesn't make sense >> with OSGi, Karaf is so so, blabla". And now we have a spec providing >> quite the same. >> I'm sorry to be upset, but this time, it doesn't sound fair to me. >> >> For Karaf, as we started effort heading to Karaf 5, it could be a good >> timing to leverage OSGi Features (we can have Karaf 5 service for Karaf >> features, and another one for OSGi Features, letting users to choose >> which one they want to use). >> >> So +0 about having to it in Felix (I can't give +1 regarding what I just >> wrote ;)). >> >> Regards >> JB >> >>> On 11/08/2021 10:56, Karl Pauls wrote: >>> On Wed, Aug 11, 2021 at 10:51 AM Jean-Baptiste Onofré <[email protected]> >> wrote: >>>> >>>> Hi David, >>>> >>>> I'm skeptical about that: >>>> >>>> 1. It looks pretty similar to Karaf Features, so, why not having it in >>>> Karaf ? >>>> 2. The naming could be confusing between Karaf Features and OSGi >> Features >>>> >>>> I think it makes more sense to have this in Karaf as it already almost >>>> exists in Karaf for a while. >>> >>> It does exist in sling for quite a while as well... >>> >>> I guess in a nutshell, we have two things called features: karaf >>> features and sling features. Now, there is an effort to have a spec in >>> the area (namely, OSGi features). >>> >>> As far as I'm concerned, putting the spec work into either sling or >>> karaf seems a little confusing - if we do it at Felix, we have a more >>> neutral ground and in the end, hopefully, both, karaf and sling can >>> support OSGi features as part of their features. >>> >>> regards, >>> >>> Karl >>> >>>> Regards >>>> JB >>>> >>>> On 11/08/2021 10:42, [email protected] wrote: >>>>> Hi all, >>>>> >>>>> As many of you know, work is happening on the next OSGi Compendium R8 >>>>> specifications [1]. >>>>> >>>>> One of the new specifications is the OSGi Feature Service (chapter 159) >>>>> [2]. I have been working on a compatible implementation in the Sling >>>>> Whiteboard [3]. My interest in this came from the Sling Feature model >> and >>>>> initially I thought a logical place for the implementation would be in >>>>> Sling. >>>>> However after some discussion at the Sling Dev list, the conclusion was >>>>> that this OSGi spec compatible implementation would be better hosted >> at a >>>>> more general OSGi community, like Apache Felix [4]. >>>>> >>>>> Therefore I would propose to host this implementation as an Apache >> Felix >>>>> subproject. For example in the 'features' subdirectory of the Felix >>>>> codebase. >>>>> >>>>> WDYT? >>>>> >>>>> Kind regards, >>>>> >>>>> David >>>>> >>>>> [1] Current draft at: https://osgi.github.io/osgi/cmpn/ >>>>> [2] https://osgi.github.io/osgi/cmpn/service.feature.html >>>>> [3] >> https://github.com/apache/sling-whiteboard/tree/master/osgi-featuremodel >>>>> [4] >>>>> >> https://lists.apache.org/thread.html/r3b548064b13718350ef08d918018f0c9b175554b6c93b95c846c044d%40%3Cdev.sling.apache.org%3E >>>>> >>> >>> >>> >>
