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

[Jean-Baptiste Onofré]

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:shu...@jahia.com]
*Sent:* Monday, April 10, 2017 4:13 AM
*To:* user@karaf.apache.org
*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 


  SKYPE | LINKEDIN  | TWITTER
   | VCARD
  





  > 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é > 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é
jbono...@apache.org 
http://blog.nanthrax.net
Talend - http://www.talend.com





--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - 

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

[Ranx]

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:shu...@jahia.com] 
Sent: Monday, April 10, 2017 4:13 AM
To: user@karaf.apache.org
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


SKYPE |   LINKEDIN |  
 TWITTER |  
 VCARD


  


  > 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é  > 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é
jbono...@apache.org  
http://blog.nanthrax.net
Talend - http://www.talend.com

 

Re: FW: Change in behaviour of karaf-maven-plugin w.r.t. dependencies for feature packaging between 4.0.x and 4.1.x

[Jean-Baptiste Onofré]

Oh it's the generate-description goal, I thought it was the assembly goal.

Regards
JB

On 04/12/2017 04:49 PM, Guillaume Nodet wrote:

Didn't we discussed that on dev@ a while ago ?
The thread is named "[DISCUSS] Feature package, feature generation and
validation", started on 13/10/2016.
IIRC, the outcome was to remove the  ‘feature-generate-descriptor’ goal from
the ‘feature’ packaging by default.

2017-04-12 16:36 GMT+02:00 Jean-Baptiste Onofré >:

Hi Arunan,

let me take a look but it sounds like a bug to me.

I keep you posted.

Regards
JB


On 04/12/2017 04:25 PM, Arunan Balasubramaniam wrote:

  Hello,

  With updating to Karaf 4.1.1 I have found a change in behaviour in the
karaf-maven-plugin seemingly no longer adding bundles from POM
dependencies. I have put a testcase up at
https://github.com/arunan-interlink/karaf-maven-plugin-features-change

that demonstrates the issue. Changing the version of karaf-maven-plugin
used in the top level POM shows the different behaviours in the output
feature file.

  Has anybody else had similar issues? Has anybody else started using
the 4.1.x Maven plugins and had this work?

  My apologies if I have missed a release note, existing issue or if
this is an incorrect configuration.

  Regards,
  Arunan


--
Jean-Baptiste Onofré
jbono...@apache.org 
http://blog.nanthrax.net
Talend - http://www.talend.com




--

Guillaume Nodet



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: FW: Change in behaviour of karaf-maven-plugin w.r.t. dependencies for feature packaging between 4.0.x and 4.1.x

[Guillaume Nodet]

Didn't we discussed that on dev@ a while ago ?
The thread is named "[DISCUSS] Feature package, feature generation and
validation", started on 13/10/2016.
IIRC, the outcome was to remove the  ‘feature-generate-descriptor’ goal
from the ‘feature’ packaging by default.

2017-04-12 16:36 GMT+02:00 Jean-Baptiste Onofré :

> Hi Arunan,
>
> let me take a look but it sounds like a bug to me.
>
> I keep you posted.
>
> Regards
> JB
>
>
> On 04/12/2017 04:25 PM, Arunan Balasubramaniam wrote:
>
>>   Hello,
>>
>>   With updating to Karaf 4.1.1 I have found a change in behaviour in the
>> karaf-maven-plugin seemingly no longer adding bundles from POM
>> dependencies. I have put a testcase up at https://github.com/arunan-inte
>> rlink/karaf-maven-plugin-features-change that demonstrates the issue.
>> Changing the version of karaf-maven-plugin used in the top level POM shows
>> the different behaviours in the output feature file.
>>
>>   Has anybody else had similar issues? Has anybody else started using the
>> 4.1.x Maven plugins and had this work?
>>
>>   My apologies if I have missed a release note, existing issue or if this
>> is an incorrect configuration.
>>
>>   Regards,
>>   Arunan
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Guillaume Nodet

FW: Change in behaviour of karaf-maven-plugin w.r.t. dependencies for feature packaging between 4.0.x and 4.1.x

[Arunan Balasubramaniam]

  Hello,

  With updating to Karaf 4.1.1 I have found a change in behaviour in the 
karaf-maven-plugin seemingly no longer adding bundles from POM dependencies. I 
have put a testcase up at 
https://github.com/arunan-interlink/karaf-maven-plugin-features-change that 
demonstrates the issue. Changing the version of karaf-maven-plugin used in the 
top level POM shows the different behaviours in the output feature file.

  Has anybody else had similar issues? Has anybody else started using the 4.1.x 
Maven plugins and had this work?

  My apologies if I have missed a release note, existing issue or if this is an 
incorrect configuration.

  Regards,
  Arunan