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, <dav...@apache.org> wrote: > Thanks! > > I'll add the initial implementation soon. > > Kind regards, > > David > > On Thu, 12 Aug 2021 at 12:16, JB Onofré <j...@nanthrax.net> 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 <david.bosscha...@gmail.com> >> 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é <j...@nanthrax.net> >> 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é < >> j...@nanthrax.net> >> >> 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, dav...@apache.org 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 >> >>>>> >> >>> >> >>> >> >>> >> >> >> >>
