Why is karaf so much easier to get working than older OSGi containers?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Why is karaf so much easier to get working than older OSGi containers?

Steinar Bang
I first encountered OSGi in 2006.  The place I worked at that time had
(prior to my hiring) selected OSGi as the platform for server side
components.

The team I worked on extended this into the GUI space by creating an
eclipse GEF-based IDE for data flows in the server system, where we
integrated the server components into the eclipse instance for
debugging.

At that time it was a very promising technology, it was defined in a
standard document that was actually readable, and it had (at that time,
if memory serves me right) one complete free software implementation
(eclipse equinox), two commercial implementations, and one free
implementation (apache felix) just getting started.

For my own part I was attracted to the lego building block possibilities
of OSGi, and the fact that we were able to get the server components
running inside eclipse and talking to eclipse GUI components by
using OSGi services (even though what the server side components and
eclipse used on top of OSGi services was very different).

But... the problem with OSGi both then, and when I started looking at it
back in 2013, was the practicalities in getting all bundle dependencies
satisfied, and finding, and working around bundle version issues.

In contrast to this, karaf has just worked for me (I took the plunge
into learning karaf in the autumn of 2016).

Or let me qualify that a little: since I started creating features for
my own bundles, as a part of the maven build, karaf has just worked for
me.

So what I'm wondering, is: why is karaf so easy when everything before
has been so hard?

Is it because there is something magical in the feature resolution,
compared to other way of starting OSGi runtimes?

Or is it just that karaf comes prepackaged with features for the pax
stuff (web, jdbc)? And that it is these prepackaged features that just
works?

Just some idle curiosity on a Sunday morning...:-)


- Steinar

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why is karaf so much easier to get working than older OSGi containers?

jbonofre
Hi Steinar,

Great e-mail !

I think Karaf just works thanks to combination of what you said: features and
resolver, prepackage features, convenient functionalities (shell, ACL, etc).

I still think we should improve the dev experience providing samples in the
distribution (as started).

Regards
JB

On 04/09/2017 08:37 AM, Steinar Bang wrote:

> I first encountered OSGi in 2006.  The place I worked at that time had
> (prior to my hiring) selected OSGi as the platform for server side
> components.
>
> The team I worked on extended this into the GUI space by creating an
> eclipse GEF-based IDE for data flows in the server system, where we
> integrated the server components into the eclipse instance for
> debugging.
>
> At that time it was a very promising technology, it was defined in a
> standard document that was actually readable, and it had (at that time,
> if memory serves me right) one complete free software implementation
> (eclipse equinox), two commercial implementations, and one free
> implementation (apache felix) just getting started.
>
> For my own part I was attracted to the lego building block possibilities
> of OSGi, and the fact that we were able to get the server components
> running inside eclipse and talking to eclipse GUI components by
> using OSGi services (even though what the server side components and
> eclipse used on top of OSGi services was very different).
>
> But... the problem with OSGi both then, and when I started looking at it
> back in 2013, was the practicalities in getting all bundle dependencies
> satisfied, and finding, and working around bundle version issues.
>
> In contrast to this, karaf has just worked for me (I took the plunge
> into learning karaf in the autumn of 2016).
>
> Or let me qualify that a little: since I started creating features for
> my own bundles, as a part of the maven build, karaf has just worked for
> me.
>
> So what I'm wondering, is: why is karaf so easy when everything before
> has been so hard?
>
> Is it because there is something magical in the feature resolution,
> compared to other way of starting OSGi runtimes?
>
> Or is it just that karaf comes prepackaged with features for the pax
> stuff (web, jdbc)? And that it is these prepackaged features that just
> works?
>
> Just some idle curiosity on a Sunday morning...:-)
>
>
> - Steinar
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why is karaf so much easier to get working than older OSGi containers?

cschneider
In reply to this post by Steinar Bang
I think it is a mixture of both. Since the start of karaf its biggest advantage was that it has predefined features for popular building blocks of applications.
You are completely right that the packaging of bundles to form a consistent deployment was always the biggest hurdle in using OSGi.

 At the start these features simply defined a list of bundles to install. Since then the feature resolver has become a lot more sophisticated (largely thanks to Guillaume). It now uses the felix resolver with a few extensions to build the optimal set of bundles for any combination of features you install. Besides this karaf also comes with definitions of system packages and other little tweaks that make it easier to use the built in spec impls the jdk contains.

There are also other environments like bndtools that provide a very good resolution of bundles but only karaf has the prepackaged features that make it so easy to start.

Christian

2017-04-09 8:37 GMT+02:00 Steinar Bang <[hidden email]>:
I first encountered OSGi in 2006.  The place I worked at that time had
(prior to my hiring) selected OSGi as the platform for server side
components.

The team I worked on extended this into the GUI space by creating an
eclipse GEF-based IDE for data flows in the server system, where we
integrated the server components into the eclipse instance for
debugging.

At that time it was a very promising technology, it was defined in a
standard document that was actually readable, and it had (at that time,
if memory serves me right) one complete free software implementation
(eclipse equinox), two commercial implementations, and one free
implementation (apache felix) just getting started.

For my own part I was attracted to the lego building block possibilities
of OSGi, and the fact that we were able to get the server components
running inside eclipse and talking to eclipse GUI components by
using OSGi services (even though what the server side components and
eclipse used on top of OSGi services was very different).

But... the problem with OSGi both then, and when I started looking at it
back in 2013, was the practicalities in getting all bundle dependencies
satisfied, and finding, and working around bundle version issues.

In contrast to this, karaf has just worked for me (I took the plunge
into learning karaf in the autumn of 2016).

Or let me qualify that a little: since I started creating features for
my own bundles, as a part of the maven build, karaf has just worked for
me.

So what I'm wondering, is: why is karaf so easy when everything before
has been so hard?

Is it because there is something magical in the feature resolution,
compared to other way of starting OSGi runtimes?

Or is it just that karaf comes prepackaged with features for the pax
stuff (web, jdbc)? And that it is these prepackaged features that just
works?

Just some idle curiosity on a Sunday morning...:-)


- Steinar




--
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why is karaf so much easier to get working than older OSGi containers?

bhillou
In reply to this post by jbonofre
I think that Karaf Boot is also important to get people started quickly. Or maybe even some kind of CLI interface and container integrations. 

I still find that building a new project with my own custom distribution is a big more work than I would like.

Not to say that I don't love Karaf, I'm using it in more and more projects (4 professional and 2 personal !)

cheers,
  Serge... 

Serge Huber
CTO & Co-Founder

T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
  

> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is a leading User Experience Platform (UXP) for Digital Transformation.


On Sun, Apr 9, 2017 at 8:50 AM, Jean-Baptiste Onofré <[hidden email]> wrote:
Hi Steinar,

Great e-mail !

I think Karaf just works thanks to combination of what you said: features and resolver, prepackage features, convenient functionalities (shell, ACL, etc).

I still think we should improve the dev experience providing samples in the distribution (as started).

Regards
JB


On 04/09/2017 08:37 AM, Steinar Bang wrote:
I first encountered OSGi in 2006.  The place I worked at that time had
(prior to my hiring) selected OSGi as the platform for server side
components.

The team I worked on extended this into the GUI space by creating an
eclipse GEF-based IDE for data flows in the server system, where we
integrated the server components into the eclipse instance for
debugging.

At that time it was a very promising technology, it was defined in a
standard document that was actually readable, and it had (at that time,
if memory serves me right) one complete free software implementation
(eclipse equinox), two commercial implementations, and one free
implementation (apache felix) just getting started.

For my own part I was attracted to the lego building block possibilities
of OSGi, and the fact that we were able to get the server components
running inside eclipse and talking to eclipse GUI components by
using OSGi services (even though what the server side components and
eclipse used on top of OSGi services was very different).

But... the problem with OSGi both then, and when I started looking at it
back in 2013, was the practicalities in getting all bundle dependencies
satisfied, and finding, and working around bundle version issues.

In contrast to this, karaf has just worked for me (I took the plunge
into learning karaf in the autumn of 2016).

Or let me qualify that a little: since I started creating features for
my own bundles, as a part of the maven build, karaf has just worked for
me.

So what I'm wondering, is: why is karaf so easy when everything before
has been so hard?

Is it because there is something magical in the feature resolution,
compared to other way of starting OSGi runtimes?

Or is it just that karaf comes prepackaged with features for the pax
stuff (web, jdbc)? And that it is these prepackaged features that just
works?

Just some idle curiosity on a Sunday morning...:-)


- Steinar


--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why is karaf so much easier to get working than older OSGi containers?

Dominik Przybysz
We have solved the OSGI quick start problem in another way in our internal project, but it is perfeclty tied to our needs.

We have forked https://github.com/spring-io/initializr and customize it to create poms, api and impl jars with configuration examples for each feature (not karaf features, but conceptual features) that we need and all dependencies added .

Now if i have to add new bundle, I just describe maven cordinates, package and features. Feature example is rest, where I obtain blueprint file with configured cxf exposing example service. Another feature is camel context where example camel context is generated with some routes, producer template and example beans.

2017-04-10 11:13 GMT+02:00 Serge Huber <[hidden email]>:
I think that Karaf Boot is also important to get people started quickly. Or maybe even some kind of CLI interface and container integrations. 

I still find that building a new project with my own custom distribution is a big more work than I would like.

Not to say that I don't love Karaf, I'm using it in more and more projects (4 professional and 2 personal !)

cheers,
  Serge... 

Serge Huber
CTO & Co-Founder

T <a href="tel:+41%2022%20361%2034%2024" value="+41223613424" target="_blank">+41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
  

> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is a leading User Experience Platform (UXP) for Digital Transformation.


On Sun, Apr 9, 2017 at 8:50 AM, Jean-Baptiste Onofré <[hidden email]> wrote:
Hi Steinar,

Great e-mail !

I think Karaf just works thanks to combination of what you said: features and resolver, prepackage features, convenient functionalities (shell, ACL, etc).

I still think we should improve the dev experience providing samples in the distribution (as started).

Regards
JB


On 04/09/2017 08:37 AM, Steinar Bang wrote:
I first encountered OSGi in 2006.  The place I worked at that time had
(prior to my hiring) selected OSGi as the platform for server side
components.

The team I worked on extended this into the GUI space by creating an
eclipse GEF-based IDE for data flows in the server system, where we
integrated the server components into the eclipse instance for
debugging.

At that time it was a very promising technology, it was defined in a
standard document that was actually readable, and it had (at that time,
if memory serves me right) one complete free software implementation
(eclipse equinox), two commercial implementations, and one free
implementation (apache felix) just getting started.

For my own part I was attracted to the lego building block possibilities
of OSGi, and the fact that we were able to get the server components
running inside eclipse and talking to eclipse GUI components by
using OSGi services (even though what the server side components and
eclipse used on top of OSGi services was very different).

But... the problem with OSGi both then, and when I started looking at it
back in 2013, was the practicalities in getting all bundle dependencies
satisfied, and finding, and working around bundle version issues.

In contrast to this, karaf has just worked for me (I took the plunge
into learning karaf in the autumn of 2016).

Or let me qualify that a little: since I started creating features for
my own bundles, as a part of the maven build, karaf has just worked for
me.

So what I'm wondering, is: why is karaf so easy when everything before
has been so hard?

Is it because there is something magical in the feature resolution,
compared to other way of starting OSGi runtimes?

Or is it just that karaf comes prepackaged with features for the pax
stuff (web, jdbc)? And that it is these prepackaged features that just
works?

Just some idle curiosity on a Sunday morning...:-)


- Steinar


--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com




--
Pozdrawiam / Regards,
Dominik Przybysz
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Why is karaf so much easier to get working than older OSGi containers?

Ranx
In reply to this post by bhillou
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why is karaf so much easier to get working than older OSGi containers?

jbonofre
Hi Brad,

I would be more than happy to restart the Karaf Boot PoC. But I was feeling a
bit alone on this ;) I started several threads on the mailing list.

I fully agree with what you said and also Serge's comments.

I will restart/update Karaf Boot during the week. If you have any idea or want
to contribute, please let me know, I will give you access to my repo !

Thanks
Regards
JB

On 04/12/2017 08:33 PM, Ranx wrote:

> I don’t think there’s been much work on Karaf Boot lately. I hope they decide to
> pick that up again and just go with an opinionated way of doing Karaf Boot
> development as Spring Boot does. For example, use the PAX and Camel CDI as the
> mechanism of bootstrap and wire up and simply leave other mechanisms alone. If
> one wants to use blueprint or DS then go for it but Karaf Boot could just ignore
> it. That doesn’t deprecate those other technologies as far as Karaf is
> concerned, it just means that the subset or mindset of Karaf Boot would be
> CDI-centric.
>
>
>
> Brad
>
>
>
> *From:*Serge Huber [mailto:[hidden email]]
> *Sent:* Monday, April 10, 2017 4:13 AM
> *To:* [hidden email]
> *Subject:* Re: Why is karaf so much easier to get working than older OSGi
> containers?
>
>
>
> I think that Karaf Boot is also important to get people started quickly. Or
> maybe even some kind of CLI interface and container integrations.
>
>
>
> I still find that building a new project with my own custom distribution is a
> big more work than I would like.
>
>
>
> Not to say that I don't love Karaf, I'm using it in more and more projects (4
> professional and 2 personal !)
>
>
>
> 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 Sun, Apr 9, 2017 at 8:50 AM, Jean-Baptiste Onofré <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Steinar,
>
>     Great e-mail !
>
>     I think Karaf just works thanks to combination of what you said: features
>     and resolver, prepackage features, convenient functionalities (shell, ACL, etc).
>
>     I still think we should improve the dev experience providing samples in the
>     distribution (as started).
>
>     Regards
>     JB
>
>
>
>     On 04/09/2017 08:37 AM, Steinar Bang wrote:
>
>         I first encountered OSGi in 2006.  The place I worked at that time had
>         (prior to my hiring) selected OSGi as the platform for server side
>         components.
>
>         The team I worked on extended this into the GUI space by creating an
>         eclipse GEF-based IDE for data flows in the server system, where we
>         integrated the server components into the eclipse instance for
>         debugging.
>
>         At that time it was a very promising technology, it was defined in a
>         standard document that was actually readable, and it had (at that time,
>         if memory serves me right) one complete free software implementation
>         (eclipse equinox), two commercial implementations, and one free
>         implementation (apache felix) just getting started.
>
>         For my own part I was attracted to the lego building block possibilities
>         of OSGi, and the fact that we were able to get the server components
>         running inside eclipse and talking to eclipse GUI components by
>         using OSGi services (even though what the server side components and
>         eclipse used on top of OSGi services was very different).
>
>         But... the problem with OSGi both then, and when I started looking at it
>         back in 2013, was the practicalities in getting all bundle dependencies
>         satisfied, and finding, and working around bundle version issues.
>
>         In contrast to this, karaf has just worked for me (I took the plunge
>         into learning karaf in the autumn of 2016).
>
>         Or let me qualify that a little: since I started creating features for
>         my own bundles, as a part of the maven build, karaf has just worked for
>         me.
>
>         So what I'm wondering, is: why is karaf so easy when everything before
>         has been so hard?
>
>         Is it because there is something magical in the feature resolution,
>         compared to other way of starting OSGi runtimes?
>
>         Or is it just that karaf comes prepackaged with features for the pax
>         stuff (web, jdbc)? And that it is these prepackaged features that just
>         works?
>
>         Just some idle curiosity on a Sunday morning...:-)
>
>
>         - Steinar
>
>
>
>     --
>     Jean-Baptiste Onofré
>     [hidden email] <mailto:[hidden email]>
>     http://blog.nanthrax.net
>     Talend - http://www.talend.com
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Why is karaf so much easier to get working than older OSGi containers?

Pratt, Jason
Count me in on this

-----Original Message-----
From: Jean-Baptiste Onofré [mailto:[hidden email]]
Sent: Wednesday, April 12, 2017 12:40 PM
To: [hidden email]
Subject: Re: Why is karaf so much easier to get working than older OSGi containers?

Hi Brad,

I would be more than happy to restart the Karaf Boot PoC. But I was feeling a bit alone on this ;) I started several threads on the mailing list.

I fully agree with what you said and also Serge's comments.

I will restart/update Karaf Boot during the week. If you have any idea or want to contribute, please let me know, I will give you access to my repo !

Thanks
Regards
JB

On 04/12/2017 08:33 PM, Ranx wrote:

> I don’t think there’s been much work on Karaf Boot lately. I hope they
> decide to pick that up again and just go with an opinionated way of
> doing Karaf Boot development as Spring Boot does. For example, use the
> PAX and Camel CDI as the mechanism of bootstrap and wire up and simply
> leave other mechanisms alone. If one wants to use blueprint or DS then
> go for it but Karaf Boot could just ignore it. That doesn’t deprecate
> those other technologies as far as Karaf is concerned, it just means
> that the subset or mindset of Karaf Boot would be CDI-centric.
>
>
>
> Brad
>
>
>
> *From:*Serge Huber [mailto:[hidden email]]
> *Sent:* Monday, April 10, 2017 4:13 AM
> *To:* [hidden email]
> *Subject:* Re: Why is karaf so much easier to get working than older
> OSGi containers?
>
>
>
> I think that Karaf Boot is also important to get people started
> quickly. Or maybe even some kind of CLI interface and container integrations.
>
>
>
> I still find that building a new project with my own custom
> distribution is a big more work than I would like.
>
>
>
> Not to say that I don't love Karaf, I'm using it in more and more
> projects (4 professional and 2 personal !)
>
>
>
> 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 Sun, Apr 9, 2017 at 8:50 AM, Jean-Baptiste Onofré <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Steinar,
>
>     Great e-mail !
>
>     I think Karaf just works thanks to combination of what you said: features
>     and resolver, prepackage features, convenient functionalities (shell, ACL, etc).
>
>     I still think we should improve the dev experience providing samples in the
>     distribution (as started).
>
>     Regards
>     JB
>
>
>
>     On 04/09/2017 08:37 AM, Steinar Bang wrote:
>
>         I first encountered OSGi in 2006.  The place I worked at that time had
>         (prior to my hiring) selected OSGi as the platform for server side
>         components.
>
>         The team I worked on extended this into the GUI space by creating an
>         eclipse GEF-based IDE for data flows in the server system, where we
>         integrated the server components into the eclipse instance for
>         debugging.
>
>         At that time it was a very promising technology, it was defined in a
>         standard document that was actually readable, and it had (at that time,
>         if memory serves me right) one complete free software implementation
>         (eclipse equinox), two commercial implementations, and one free
>         implementation (apache felix) just getting started.
>
>         For my own part I was attracted to the lego building block possibilities
>         of OSGi, and the fact that we were able to get the server components
>         running inside eclipse and talking to eclipse GUI components by
>         using OSGi services (even though what the server side components and
>         eclipse used on top of OSGi services was very different).
>
>         But... the problem with OSGi both then, and when I started looking at it
>         back in 2013, was the practicalities in getting all bundle dependencies
>         satisfied, and finding, and working around bundle version issues.
>
>         In contrast to this, karaf has just worked for me (I took the plunge
>         into learning karaf in the autumn of 2016).
>
>         Or let me qualify that a little: since I started creating features for
>         my own bundles, as a part of the maven build, karaf has just worked for
>         me.
>
>         So what I'm wondering, is: why is karaf so easy when everything before
>         has been so hard?
>
>         Is it because there is something magical in the feature resolution,
>         compared to other way of starting OSGi runtimes?
>
>         Or is it just that karaf comes prepackaged with features for the pax
>         stuff (web, jdbc)? And that it is these prepackaged features that just
>         works?
>
>         Just some idle curiosity on a Sunday morning...:-)
>
>
>         - Steinar
>
>
>
>     --
>     Jean-Baptiste Onofré
>     [hidden email] <mailto:[hidden email]>
>     http://blog.nanthrax.net
>     Talend - http://www.talend.com
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Loading...