You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by da...@apache.org on 2021/08/11 08:42:45 UTC
[Proposal] New subproject: OSGi Features
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
Re: [Proposal] New subproject: OSGi Features
Posted by Karl Pauls <ka...@gmail.com>.
I think that is a good idea.
regards,
Karl
On Wed, Aug 11, 2021 at 10:43 AM <da...@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
--
Karl Pauls
karlpauls@gmail.com
Re: [Proposal] New subproject: OSGi Features
Posted by da...@apache.org.
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, <da...@apache.org> 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, <da...@apache.org> wrote:
>
>> Thanks!
>>
>> I'll add the initial implementation soon.
>>
>> Kind regards,
>>
>> David
>>
>> On Thu, 12 Aug 2021 at 12:16, JB Onofré <jb...@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 <da...@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é <jb...@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é <
>>> jb@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, davidb@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
>>> >>>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>>
>>>
Re: [Proposal] New subproject: OSGi Features
Posted by da...@apache.org.
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, <da...@apache.org> wrote:
> Thanks!
>
> I'll add the initial implementation soon.
>
> Kind regards,
>
> David
>
> On Thu, 12 Aug 2021 at 12:16, JB Onofré <jb...@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 <da...@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é <jb...@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é <
>> jb@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, davidb@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
>> >>>>>
>> >>>
>> >>>
>> >>>
>> >>
>>
>>
Re: [Proposal] New subproject: OSGi Features
Posted by da...@apache.org.
Thanks!
I'll add the initial implementation soon.
Kind regards,
David
On Thu, 12 Aug 2021 at 12:16, JB Onofré <jb...@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 <da...@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é <jb...@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é <jb@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, davidb@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
> >>>>>
> >>>
> >>>
> >>>
> >>
>
>
Re: [Proposal] New subproject: OSGi Features
Posted by JB Onofré <jb...@nanthrax.net>.
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 <da...@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é <jb...@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é <jb...@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, davidb@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
>>>>>
>>>
>>>
>>>
>>
Re: [Proposal] New subproject: OSGi Features
Posted by David Bosschaert <da...@gmail.com>.
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é <jb...@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é <jb...@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, davidb@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
> >>>
> >
> >
> >
>
Re: [Proposal] New subproject: OSGi Features
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@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, davidb@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
>>>
>
>
>
Re: [Proposal] New subproject: OSGi Features
Posted by Karl Pauls <ka...@gmail.com>.
On Wed, Aug 11, 2021 at 10:51 AM Jean-Baptiste Onofré <jb...@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, davidb@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
> >
--
Karl Pauls
karlpauls@gmail.com
Re: [Proposal] New subproject: OSGi Features
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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.
Regards
JB
On 11/08/2021 10:42, davidb@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
>