Hi all, Thanks for the positive reactions on the PR! I'd like to go with lazy consensus here: if nobody objects by the end of Tuesday August 17, I'll merge the PR.
Kind regards, David On Thu, 12 Aug 2021 at 16:25, <[email protected]> wrote: > Hi all, > > I created https://issues.apache.org/jira/browse/FELIX-6444 for the > contribution. > > Pull request: https://github.com/apache/felix-dev/pull/88 > > Best regards, > > David > > On Thu, 12 Aug 2021 at 13:28, <[email protected]> wrote: > >> Thanks! >> >> I'll add the initial implementation soon. >> >> Kind regards, >> >> David >> >> On Thu, 12 Aug 2021 at 12:16, JB Onofré <[email protected]> wrote: >> >>> 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 >>> >>>>> >>> >>> >>> >>> >>> >>> >>> >> >>> >>>
