[GitHub] [felix-dev] stbischof commented on pull request #88: FELIX-6444 Contribute a compatible implementation of OSGi Features
stbischof commented on pull request #88: URL: https://github.com/apache/felix-dev/pull/88#issuecomment-897883730 happy to see this here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@felix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [Proposal] New subproject: OSGi Features
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, wrote: > Thanks! > > I'll add the initial implementation soon. > > Kind regards, > > David > > On Thu, 12 Aug 2021 at 12:16, JB Onofré 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 >> 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=America%2FToronto >> > [8] https://accounts.eclipse.org/mailing-list/osgi-dev >> > >> > >> >> On Wed, 11 Aug 2021 at 10:08, Jean-Baptiste Onofré >> 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
[GitHub] [felix-dev] bosschaert opened a new pull request #88: FELIX-6444 Contribute a compatible implementation of OSGi Features
bosschaert opened a new pull request #88: URL: https://github.com/apache/felix-dev/pull/88 As discussed at the Felix Mailing list: https://www.mail-archive.com/dev%40felix.apache.org/msg52338.html This implementation was initially made in the Apache Sling Whiteboard component at https://github.com/apache/sling-whiteboard/tree/master/osgi-featuremodel -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@felix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work started] (FELIX-6444) Contribute a compatible implementation of OSGi Features
[ https://issues.apache.org/jira/browse/FELIX-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-6444 started by A. J. David Bosschaert. - > Contribute a compatible implementation of OSGi Features > --- > > Key: FELIX-6444 > URL: https://issues.apache.org/jira/browse/FELIX-6444 > Project: Felix > Issue Type: New Feature >Reporter: A. J. David Bosschaert >Assignee: A. J. David Bosschaert >Priority: Major > > As discussed on the Felix Dev mailing list > (https://www.mail-archive.com/dev%40felix.apache.org/msg52338.html) a > compatible implementation of the OSGi Feature Service should be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-6444) Contribute a compatible implementation of OSGi Features
[ https://issues.apache.org/jira/browse/FELIX-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. J. David Bosschaert updated FELIX-6444: -- Description: As discussed on the Felix Dev mailing list (https://www.mail-archive.com/dev%40felix.apache.org/msg52338.html) a compatible implementation of the OSGi Feature Service should be added. (was: As discussed on the Felix Dev mailing list a compatible implementation of the OSGi Feature Service should be added.) > Contribute a compatible implementation of OSGi Features > --- > > Key: FELIX-6444 > URL: https://issues.apache.org/jira/browse/FELIX-6444 > Project: Felix > Issue Type: New Feature >Reporter: A. J. David Bosschaert >Assignee: A. J. David Bosschaert >Priority: Major > > As discussed on the Felix Dev mailing list > (https://www.mail-archive.com/dev%40felix.apache.org/msg52338.html) a > compatible implementation of the OSGi Feature Service should be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FELIX-6444) Contribute a compatible implementation of OSGi Features
A. J. David Bosschaert created FELIX-6444: - Summary: Contribute a compatible implementation of OSGi Features Key: FELIX-6444 URL: https://issues.apache.org/jira/browse/FELIX-6444 Project: Felix Issue Type: New Feature Reporter: A. J. David Bosschaert Assignee: A. J. David Bosschaert As discussed on the Felix Dev mailing list a compatible implementation of the OSGi Feature Service should be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [Proposal] New subproject: OSGi Features
Thanks! I'll add the initial implementation soon. Kind regards, David On Thu, 12 Aug 2021 at 12:16, JB Onofré 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 > 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=America%2FToronto > > [8] https://accounts.eclipse.org/mailing-list/osgi-dev > > > > > >> On Wed, 11 Aug 2021 at 10:08, Jean-Baptiste Onofré > 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é > > >> 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, >
Re: [Proposal] New subproject: OSGi Features
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 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=America%2FToronto > [8] https://accounts.eclipse.org/mailing-list/osgi-dev > > >> On Wed, 11 Aug 2021 at 10:08, Jean-Baptiste Onofré 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é >> 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
