karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ɓukasz Dywicki <l...@code-house.org>
Subject Re: FYI, OSGi Features RFP
Date Thu, 12 Apr 2018 22:47:53 GMT
Hey David & Christian & Guilliame & Grzegorze
Great to hear that from David, as an insider. It is super cool to have
Christian watching things from karaf side.

I am sending this reply to share my personal view on the past and hope
in future standard.
I rely on our features mechanism since its early days (before graduating
to top level project) and the beauty come from its initial simplicity.
You know in early days it was nothing but a way to install bundles in
runtime. Later we got additional steps such validation, verification,
configuration files and so on, not to mention KAR packaging.
It did work because it did a simple thing and did it right. This is
great success compared to mostly failed efforts of ESA/EBA formats which
didn't (I think) get any adoption beside commercial products.
I'm not sure if eclipse provisioning model is a valid comparision as its
granularity is completely different. Karaf features never worked at
package level while Eclipse P2 is built around requirements and
capabilities model. While it is great way to control everything it is
not that great in mainanance. Felix Resolver which is implementation of
approprieate spec in this area handles that already.
I haven't heard much of P2 besise eclipse plugin ecosystem, its
documentation is lacky and its embedding requires a lot of work (had an
attempt to get it running under Karaf logn time ago). Its super slow
when used for builds - I initially loveld Tycho. These days when I see
it used for non-eclipse plugin projects, and there are still some, I ask
myself what for?

Frankly speaking, the less we can care about requirements and
capabilities, the easier adoption will be. A lot of "bad press" of osgi
comes from huge learning curve, non popular toolkits and Eclipse
ecosystem itself. I haven't made any statistics but I believe that
love-hate relationship from Eclipse gets spread to the OSGi, quite often
without reason. If spec will keep whole thing closer to maven, and it
seems it will, undarstanding of mechanism will be much easier. There
will be no barrier at least at entry level.
In past years I meet no single person who worked in Java and could
understand requirements and capabilities model of P2 (and osgi) from
first touch. Because almost every developer can "speak" maven and its
binaries distribution model it is indeed wise to rely on that.

Grzegorze and Guilliame - Red Hat so you can track specification
development. Not sure how it works now but in the past you just had to
use company mail to request new account. I remember I did it this way
and comment on some things realted to http service while I was working
at RH. I am not sure if RH didn't step from higher level membership
because even my micro company is supporter..

Kind regards,
Twitter: @ldywicki
Blog: http://dywicki.pl
Company: http://code-house.org

On 09.04.2018 13:26, davidb@apache.org wrote:
> Hi all,
> As Guillaume says OSGi Alliance is not an open source organisation. It is a
> Standards Development Organisation (SDO) where all the OSGi specifications
> are developed by a community of members. These members include committers
> from Apache, Eclipse and other open source organisations. OSGi is an open
> organisation, any company can join and participate. OSGi is not dominated
> by one company or individual, specs are developed by volunteers from the
> membership and the development process is democratic and open [1]. While
> OSGi is driven by its members, there are public feedback channels, see at
> the bottom of [1], so if someone is concerned about the direction of a
> spec, post feedback, talk to any of the OSGi members or become involved
> yourself :)
> Most of the OSGi specs are developed through open source projects, many in
> Apache. Implementation of an OSGi spec is entirely optional, btw.
> Coming back to the RFP that I posted to the OSGi design git repo... This
> came from the observation that there are still a number of different ways
> to define OSGi applications. Grzegorz mentions Eclipse features below.
> Karaf obviously has Karaf Features, Apache Sling has a provisioning
> model/feature model and there are even more. The idea for a spec would be
> that it would be nice to have a portable description of OSGi applications
> that each community would understand. This is often how OSGi specs get
> started: the observation that multiple projects try to solve the same
> problem, in fact in most cases there were already pre-existing solutions
> before a spec is written.
> The RFP only states requirements, and these haven't even been discussed in
> OSGi yet, but obviously it would be great if all interested projects have
> representation in the OSGi discussions, so it's great that Christian has
> already offered to wear the Karaf hat.
> So... we're really at step 0. I personally think it's worth trying to come
> up with a portable application/feature description model in an OSGi spec,
> and that's why I'm proposing the RFP. If you're worried, interested or
> excited by this: please feel free to provide feedback and help out! :)
> Best regards,
> David
> PS full disclosure: besides being an Apache commiter, I work for Adobe and
> am co-chair of the OSGi Enterprise Expert Group [2]
> [1] https://github.com/osgi/design
> [2] https://www.osgi.org/about-us/working-groups/enterprise/
> On 9 April 2018 at 11:39, Grzegorz Grzybek <gr.grzybek@gmail.com> wrote:
>> Hello
>> And how about Eclipse features? From certain perspective, these are also
>> higher-level concept than standard bundles, but probably not that
>> runtime-specific (I mean there's no "feature service" you can obtain and
>> for example list installed features).
>> I'm also a bit worried about forcing Karaf to implement post-factum
>> standard...
>> regards
>> Grzegorz Grzybek
>> 2018-04-09 12:31 GMT+02:00 Christian Schneider <chris@die-schneider.net>:
>>> I think the RFP is based on the prototype of the sling feature model.
>>> See:
>>> https://github.com/apache/sling-whiteboard/tree/master/featuremodel
>>> As far as I know this is indeed inspired by karaf. I am not sure how
>>> compatible it is at the moment. I will try to participate in the
>>> standardisation effort and try to achieve some compatibility with karaf.
>>> Christian
>>> 2018-04-09 11:35 GMT+02:00 Guillaume Nodet <gnodet@apache.org>:
>>>> I was not in any way aware of this RFP and I'm not part of the process,
>>> but
>>>> this looks really inspired from Karaf Features at least.
>>>> The author, David B. is a Karaf committer, so he may be able to comment
>>> on
>>>> what he has in mind.
>>>> Having said that, I'm not so sure it's a good thing for Karaf, but
>> we'll
>>>> see. Hopefully things will go well this time, but I've already seen
>>> several
>>>> things go wrong at the OSGi EEG...
>>>> Guillaume
>>>> 2018-04-09 11:07 GMT+02:00 Serge Huber <shuber@jahia.com>:
>>>>> Interesting ! Is it planned to be based on Karaf Features model ?
>>>>> cheers,
>>>>>   Serge...
>>>>> Serge Huber
>>>>> CTO & Co-Founder
>>>>> T +41 22 361 3424
>>>>> 9 route des Jeunes | 1227 Acacias | Switzerland
>>>>> jahia.com <http://www.jahia.com/>
>>>>> SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
>>>>> <https://twitter.com/sergehuber> | VCARD
>>>>> <http://www.jahia.com/vcard/HuberSerge.vcf>
>>>>>> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get
>> trained
>>>> and
>>>>> to discover why Jahia is a leading User Experience Platform (UXP) for
>>>>> Digital Transformation.
>>>>> On Mon, Apr 9, 2018 at 10:54 AM, Guillaume Nodet <gnodet@apache.org>
>>>>> wrote:
>>>>>> See https://github.com/osgi/design/blob/master/rfps/rfp-
>>>>> 0188-Features.pdf
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>> Computer Scientist
>>> http://www.adobe.com

View raw message