subject:"Re\: Bndtools \& Karaf \: the right way"

Maybe a example in Karaf distro and documentation would be great as well
(focused on Karaf as runtime).

Regards
JB

On 14/02/2019 14:03, Raymond Auge wrote:
> Maybe it might be worth in the next month or so if Christian and I could
> do a kind of webinar on the modern Maven way to do OSGi development.
> 
> What do you think Christian, would you be up for something like that?
> 
> - Ray
> 
> On Thu, Feb 14, 2019, 07:59 Christian Schneider   wrote:
> 
> The new maven build in bndtools is now a plain maven build.
> Of course the bndtools examples favour the bnd-maven-plugin instead
> of the maven-bundle-plugin but that is more like left and right twix :-)
> 
> The only real difference is how the bundles are then assembled into
> a runable application. 
> 
> There bndtools uses a bndrun file which points to a repository
> (based on maven now) and requirements. The output is a runnable jar.
> 
> For karaf you create a feature with your bundles and dependencies
> typically as feature dependencies. Then in a second step you can
> also have a karaf custom distro to create a complete server
> (application).
> 
> So it is now perfectly possible to produce a bndtools based assembly
> and a karaf feature and optionally a custom distro in the same build. 
> 
> The only sad thing is that the deployment descriptions are not yet
> compatible. As both karaf and bndtools use a bundle repository under
> the hood I think this can be improved.
> 
> Christian
> 
> Am Do., 14. Feb. 2019 um 13:46 Uhr schrieb Jean-Baptiste Onofré
> mailto:j...@nanthrax.net>>:
> 
> Hi Ray,
> 
> does it mean that bundle can be created in bndtools, then upload
> in a
> Maven repository, and installed in Karaf ?
> Maybe the only missing piece is that bndtools generate a
> features XML to
> have a complete story.
> 
> Regards
> JB
> 
> On 14/02/2019 13:44, Raymond Auge wrote:
> > Perhaps it would be better, rather than switching to the BND
> Workspace
> > model to simply use the BND/Bndtools Maven/m2e support. It's
> very good
> > now and has parity in large part with the BND Workspace. The
> upcoming
> > release especially should break lots of barriers.
> >
> > Just a suggestion.
> >
> > - Ray
> >
> > On Thu, Feb 14, 2019, 07:37 Jean-Baptiste Onofré
> mailto:j...@nanthrax.net>
> > > wrote:
> >
> >     Hi,
> >
> >     We didn't move forward a lot. I remember there was some
> discussion to
> >     have a "Karaf exporter" in bndtools and I proposed my help
> on this.
> >     I didn't move forward yet.
> >
> >     Do you already know what you have in mind (if you could
> describe the use
> >     case, that would be great) ?
> >
> >     Regards
> >     JB
> >
> >     On 14/02/2019 13:20, kamilantlgc wrote:
> >     > Dear Karaf User group,
> >     >
> >     > I have stumbled upon the exact problem - how to join
> Karaf and
> >     Bndtools
> >     > together "the right way" (this conversation is the first
> result in
> >     Google by
> >     > the way: https://www.google.com/search?q=karaf+bnd).
> >     >
> >     > I've read the topic and was happy to see that Guillaume
> asked to
> >     fill Jira
> >     > issue.
> >     > Then I've read with interest that JB is just "building
> the new
> >     SNAPSHOT to
> >     > test if the couple of issues".
> >     > And then I navigated to the issue created by dleangen
> >     > (https://issues.apache.org/jira/browse/KARAF-4160) just
> to see
> >     that it's
> >     > status is "Won't fix"...
> >     >
> >     > Anyway - does anybody on this group already figured it
> out how to
> >     join Karaf
> >     > and Bnd to play nicely together?
> >     >
> >     > Kind regards,
> >     > Kamil
> >     >
> >     >
> >     >
> >     > --
> >     > Sent from:
> http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> >     >
> >
> >     --
> >     Jean-Baptiste Onofré
> >     jbono...@apache.org 
> >
> >     http://blog.nanthrax.net
> >     Talend - http://www.talend.com
> >
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org 
>

Re: Bndtools & Karaf : the right way

One is not opposite with the other.

Karaf can also support "static" assembly. It's already possible but not
so easy in term of tooling.
I'm adding an example in the distribution to illustrate this, and it's
definitely one of the purpose of "kloud initiative" (tooling).

Regards
JB

On 14/02/2019 14:07, David Daniel wrote:
> In my opinion there is more than this.  Having worked with both they
> bring different things to the table because I love the static build time
> checks that bnd brings and I love that it produces a single jar output. 
> From karaf I find it really easy to add features, and capabilities that
> are well tested by the community.  With bndtools I know every library
> and keep them updated manually in my bndrun file (I do not use
> eclipse).  This keeps my build small and takes away problems like having
> 3 features bring in 3 different json libraries but at the expense of
> having to micromanage dependencies and making things more complicated
> for the younger developers on my team that are new to OSGI.  I think
> there is a reason open source projects like openhab and opendaylight
> have chosen karaf for a modular system that many developers can get
> started with.  I commented on the other thread about a static build for
> karaf for docker.  What I would really like to see is karaf make sure
> its features are buildable in a compatible way with the new osgi
> features spec so I can use some of the well tested karaf features.  I
> would also like to see a good standard choice for creating the
> configuration of those features.  I am hoping that brings the two
> communities closer to compatibility.   
> 
> David Daniel
> 
> On Thu, Feb 14, 2019 at 8:03 AM Jean-Baptiste Onofré  > wrote:
> 
> Thanks !
> 
> I'm happy to see that finally bndtools went to Maven space ;)
> 
> Regards
> JB
> 
> On 14/02/2019 13:59, Raymond Auge wrote:
> >
> >
> > On Thu, Feb 14, 2019, 07:46 Jean-Baptiste Onofré  
> > > wrote:
> >
> >     Hi Ray,
> >
> >     does it mean that bundle can be created in bndtools, then
> upload in a
> >     Maven repository,
> >
> >
> > Yeah, whatever you can do in Maven/m2e is available.
> >
> >     and installed in Karaf ?
> >
> >
> > not sure if you are referring to a realtime, seamless operation here
> > during development or just install later.
> >
> > - install later; no problem at all
> > - seamless, realtime install during development; will need a small bit
> > of work
> >
> >     Maybe the only missing piece is that bndtools generate a
> features XML to
> >     have a complete story.
> >
> >
> > Yeah, if there's a Maven tooling for this , you could just use it.
> > However, if there's need for a specific integration, maybe in the next
> > dev cycle I could lend a hand to build this.
> >
> > Sincerely,
> > - Ray
> >
> >
> >     Regards
> >     JB
> >
> >     On 14/02/2019 13:44, Raymond Auge wrote:
> >     > Perhaps it would be better, rather than switching to the BND
> Workspace
> >     > model to simply use the BND/Bndtools Maven/m2e support. It's
> very good
> >     > now and has parity in large part with the BND Workspace. The
> upcoming
> >     > release especially should break lots of barriers.
> >     >
> >     > Just a suggestion.
> >     >
> >     > - Ray
> >     >
> >     > On Thu, Feb 14, 2019, 07:37 Jean-Baptiste Onofré
> mailto:j...@nanthrax.net>
> >     >
> >     > 
> >> wrote:
> >     >
> >     >     Hi,
> >     >
> >     >     We didn't move forward a lot. I remember there was some
> >     discussion to
> >     >     have a "Karaf exporter" in bndtools and I proposed my
> help on
> >     this.
> >     >     I didn't move forward yet.
> >     >
> >     >     Do you already know what you have in mind (if you could
> >     describe the use
> >     >     case, that would be great) ?
> >     >
> >     >     Regards
> >     >     JB
> >     >
> >     >     On 14/02/2019 13:20, kamilantlgc wrote:
> >     >     > Dear Karaf User group,
> >     >     >
> >     >     > I have stumbled upon the exact problem - how to join
> Karaf and
> >     >     Bndtools
> >     >     > together "the right way" (this conversation is the first
> >     result in
> >     >     Google by
> >     >     > the way: https://www.google.com/search?q=karaf+bnd).
> >     >     >
> >     >     > I've read the topic and was happy to see that
> Guillaume asked to
> >

Re: Bndtools & Karaf : the right way

2019-02-14 Thread David Daniel

In my opinion there is more than this.  Having worked with both they bring
different things to the table because I love the static build time checks
that bnd brings and I love that it produces a single jar output.  From
karaf I find it really easy to add features, and capabilities that are well
tested by the community.  With bndtools I know every library and keep them
updated manually in my bndrun file (I do not use eclipse).  This keeps my
build small and takes away problems like having 3 features bring in 3
different json libraries but at the expense of having to micromanage
dependencies and making things more complicated for the younger developers
on my team that are new to OSGI.  I think there is a reason open source
projects like openhab and opendaylight have chosen karaf for a modular
system that many developers can get started with.  I commented on the other
thread about a static build for karaf for docker.  What I would really like
to see is karaf make sure its features are buildable in a compatible way
with the new osgi features spec so I can use some of the well tested karaf
features.  I would also like to see a good standard choice for creating the
configuration of those features.  I am hoping that brings the two
communities closer to compatibility.

David Daniel

On Thu, Feb 14, 2019 at 8:03 AM Jean-Baptiste Onofré 
wrote:

> Thanks !
>
> I'm happy to see that finally bndtools went to Maven space ;)
>
> Regards
> JB
>
> On 14/02/2019 13:59, Raymond Auge wrote:
> >
> >
> > On Thu, Feb 14, 2019, 07:46 Jean-Baptiste Onofré  >  wrote:
> >
> > Hi Ray,
> >
> > does it mean that bundle can be created in bndtools, then upload in a
> > Maven repository,
> >
> >
> > Yeah, whatever you can do in Maven/m2e is available.
> >
> > and installed in Karaf ?
> >
> >
> > not sure if you are referring to a realtime, seamless operation here
> > during development or just install later.
> >
> > - install later; no problem at all
> > - seamless, realtime install during development; will need a small bit
> > of work
> >
> > Maybe the only missing piece is that bndtools generate a features
> XML to
> > have a complete story.
> >
> >
> > Yeah, if there's a Maven tooling for this , you could just use it.
> > However, if there's need for a specific integration, maybe in the next
> > dev cycle I could lend a hand to build this.
> >
> > Sincerely,
> > - Ray
> >
> >
> > Regards
> > JB
> >
> > On 14/02/2019 13:44, Raymond Auge wrote:
> > > Perhaps it would be better, rather than switching to the BND
> Workspace
> > > model to simply use the BND/Bndtools Maven/m2e support. It's very
> good
> > > now and has parity in large part with the BND Workspace. The
> upcoming
> > > release especially should break lots of barriers.
> > >
> > > Just a suggestion.
> > >
> > > - Ray
> > >
> > > On Thu, Feb 14, 2019, 07:37 Jean-Baptiste Onofré  > 
> > > > wrote:
> > >
> > > Hi,
> > >
> > > We didn't move forward a lot. I remember there was some
> > discussion to
> > > have a "Karaf exporter" in bndtools and I proposed my help on
> > this.
> > > I didn't move forward yet.
> > >
> > > Do you already know what you have in mind (if you could
> > describe the use
> > > case, that would be great) ?
> > >
> > > Regards
> > > JB
> > >
> > > On 14/02/2019 13:20, kamilantlgc wrote:
> > > > Dear Karaf User group,
> > > >
> > > > I have stumbled upon the exact problem - how to join Karaf
> and
> > > Bndtools
> > > > together "the right way" (this conversation is the first
> > result in
> > > Google by
> > > > the way: https://www.google.com/search?q=karaf+bnd).
> > > >
> > > > I've read the topic and was happy to see that Guillaume
> asked to
> > > fill Jira
> > > > issue.
> > > > Then I've read with interest that JB is just "building the
> new
> > > SNAPSHOT to
> > > > test if the couple of issues".
> > > > And then I navigated to the issue created by dleangen
> > > > (https://issues.apache.org/jira/browse/KARAF-4160) just to
> see
> > > that it's
> > > > status is "Won't fix"...
> > > >
> > > > Anyway - does anybody on this group already figured it out
> > how to
> > > join Karaf
> > > > and Bnd to play nicely together?
> > > >
> > > > Kind regards,
> > > > Kamil
> > > >
> > > >
> > > >
> > > > --
> > > > Sent from:
> > http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> > > >
> > >
> > > --
> > > Jean-Baptiste Onofré
> > > jbono...@apache.org 
>

Re: Bndtools & Karaf : the right way

2019-02-14 Thread Raymond Auge

Maybe it might be worth in the next month or so if Christian and I could do
a kind of webinar on the modern Maven way to do OSGi development.

What do you think Christian, would you be up for something like that?

- Ray

On Thu, Feb 14, 2019, 07:59 Christian Schneider  The new maven build in bndtools is now a plain maven build.
> Of course the bndtools examples favour the bnd-maven-plugin instead of the
> maven-bundle-plugin but that is more like left and right twix :-)
>
> The only real difference is how the bundles are then assembled into a
> runable application.
>
> There bndtools uses a bndrun file which points to a repository (based on
> maven now) and requirements. The output is a runnable jar.
>
> For karaf you create a feature with your bundles and dependencies
> typically as feature dependencies. Then in a second step you can also have
> a karaf custom distro to create a complete server (application).
>
> So it is now perfectly possible to produce a bndtools based assembly and a
> karaf feature and optionally a custom distro in the same build.
>
> The only sad thing is that the deployment descriptions are not yet
> compatible. As both karaf and bndtools use a bundle repository under the
> hood I think this can be improved.
>
> Christian
>
> Am Do., 14. Feb. 2019 um 13:46 Uhr schrieb Jean-Baptiste Onofré <
> j...@nanthrax.net>:
>
>> Hi Ray,
>>
>> does it mean that bundle can be created in bndtools, then upload in a
>> Maven repository, and installed in Karaf ?
>> Maybe the only missing piece is that bndtools generate a features XML to
>> have a complete story.
>>
>> Regards
>> JB
>>
>> On 14/02/2019 13:44, Raymond Auge wrote:
>> > Perhaps it would be better, rather than switching to the BND Workspace
>> > model to simply use the BND/Bndtools Maven/m2e support. It's very good
>> > now and has parity in large part with the BND Workspace. The upcoming
>> > release especially should break lots of barriers.
>> >
>> > Just a suggestion.
>> >
>> > - Ray
>> >
>> > On Thu, Feb 14, 2019, 07:37 Jean-Baptiste Onofré > >  wrote:
>> >
>> > Hi,
>> >
>> > We didn't move forward a lot. I remember there was some discussion
>> to
>> > have a "Karaf exporter" in bndtools and I proposed my help on this.
>> > I didn't move forward yet.
>> >
>> > Do you already know what you have in mind (if you could describe
>> the use
>> > case, that would be great) ?
>> >
>> > Regards
>> > JB
>> >
>> > On 14/02/2019 13:20, kamilantlgc wrote:
>> > > Dear Karaf User group,
>> > >
>> > > I have stumbled upon the exact problem - how to join Karaf and
>> > Bndtools
>> > > together "the right way" (this conversation is the first result in
>> > Google by
>> > > the way: https://www.google.com/search?q=karaf+bnd).
>> > >
>> > > I've read the topic and was happy to see that Guillaume asked to
>> > fill Jira
>> > > issue.
>> > > Then I've read with interest that JB is just "building the new
>> > SNAPSHOT to
>> > > test if the couple of issues".
>> > > And then I navigated to the issue created by dleangen
>> > > (https://issues.apache.org/jira/browse/KARAF-4160) just to see
>> > that it's
>> > > status is "Won't fix"...
>> > >
>> > > Anyway - does anybody on this group already figured it out how to
>> > join Karaf
>> > > and Bnd to play nicely together?
>> > >
>> > > Kind regards,
>> > > Kamil
>> > >
>> > >
>> > >
>> > > --
>> > > Sent from:
>> http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>> > >
>> >
>> > --
>> > 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 - http://www.talend.com
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
>

Re: Bndtools & Karaf : the right way

Thanks !

I'm happy to see that finally bndtools went to Maven space ;)

Regards
JB

On 14/02/2019 13:59, Raymond Auge wrote:
> 
> 
> On Thu, Feb 14, 2019, 07:46 Jean-Baptiste Onofré   wrote:
> 
> Hi Ray,
> 
> does it mean that bundle can be created in bndtools, then upload in a
> Maven repository,
> 
> 
> Yeah, whatever you can do in Maven/m2e is available.
> 
> and installed in Karaf ?
> 
> 
> not sure if you are referring to a realtime, seamless operation here
> during development or just install later.
> 
> - install later; no problem at all
> - seamless, realtime install during development; will need a small bit
> of work
> 
> Maybe the only missing piece is that bndtools generate a features XML to
> have a complete story.
> 
> 
> Yeah, if there's a Maven tooling for this , you could just use it.
> However, if there's need for a specific integration, maybe in the next
> dev cycle I could lend a hand to build this.
> 
> Sincerely,
> - Ray
> 
> 
> Regards
> JB
> 
> On 14/02/2019 13:44, Raymond Auge wrote:
> > Perhaps it would be better, rather than switching to the BND Workspace
> > model to simply use the BND/Bndtools Maven/m2e support. It's very good
> > now and has parity in large part with the BND Workspace. The upcoming
> > release especially should break lots of barriers.
> >
> > Just a suggestion.
> >
> > - Ray
> >
> > On Thu, Feb 14, 2019, 07:37 Jean-Baptiste Onofré  
> > > wrote:
> >
> >     Hi,
> >
> >     We didn't move forward a lot. I remember there was some
> discussion to
> >     have a "Karaf exporter" in bndtools and I proposed my help on
> this.
> >     I didn't move forward yet.
> >
> >     Do you already know what you have in mind (if you could
> describe the use
> >     case, that would be great) ?
> >
> >     Regards
> >     JB
> >
> >     On 14/02/2019 13:20, kamilantlgc wrote:
> >     > Dear Karaf User group,
> >     >
> >     > I have stumbled upon the exact problem - how to join Karaf and
> >     Bndtools
> >     > together "the right way" (this conversation is the first
> result in
> >     Google by
> >     > the way: https://www.google.com/search?q=karaf+bnd).
> >     >
> >     > I've read the topic and was happy to see that Guillaume asked to
> >     fill Jira
> >     > issue.
> >     > Then I've read with interest that JB is just "building the new
> >     SNAPSHOT to
> >     > test if the couple of issues".
> >     > And then I navigated to the issue created by dleangen
> >     > (https://issues.apache.org/jira/browse/KARAF-4160) just to see
> >     that it's
> >     > status is "Won't fix"...
> >     >
> >     > Anyway - does anybody on this group already figured it out
> how to
> >     join Karaf
> >     > and Bnd to play nicely together?
> >     >
> >     > Kind regards,
> >     > Kamil
> >     >
> >     >
> >     >
> >     > --
> >     > Sent from:
> http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> >     >
> >
> >     --
> >     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 - http://www.talend.com
> 

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

Re: Bndtools & Karaf : the right way

2019-02-14 Thread Raymond Auge

On Thu, Feb 14, 2019, 07:46 Jean-Baptiste Onofré  Hi Ray,
>
> does it mean that bundle can be created in bndtools, then upload in a
> Maven repository,


Yeah, whatever you can do in Maven/m2e is available.

and installed in Karaf ?
>

not sure if you are referring to a realtime, seamless operation here during
development or just install later.

- install later; no problem at all
- seamless, realtime install during development; will need a small bit of
work

Maybe the only missing piece is that bndtools generate a features XML to
> have a complete story.
>

Yeah, if there's a Maven tooling for this , you could just use it. However,
if there's need for a specific integration, maybe in the next dev cycle I
could lend a hand to build this.

Sincerely,
- Ray


> Regards
> JB
>
> On 14/02/2019 13:44, Raymond Auge wrote:
> > Perhaps it would be better, rather than switching to the BND Workspace
> > model to simply use the BND/Bndtools Maven/m2e support. It's very good
> > now and has parity in large part with the BND Workspace. The upcoming
> > release especially should break lots of barriers.
> >
> > Just a suggestion.
> >
> > - Ray
> >
> > On Thu, Feb 14, 2019, 07:37 Jean-Baptiste Onofré  >  wrote:
> >
> > Hi,
> >
> > We didn't move forward a lot. I remember there was some discussion to
> > have a "Karaf exporter" in bndtools and I proposed my help on this.
> > I didn't move forward yet.
> >
> > Do you already know what you have in mind (if you could describe the
> use
> > case, that would be great) ?
> >
> > Regards
> > JB
> >
> > On 14/02/2019 13:20, kamilantlgc wrote:
> > > Dear Karaf User group,
> > >
> > > I have stumbled upon the exact problem - how to join Karaf and
> > Bndtools
> > > together "the right way" (this conversation is the first result in
> > Google by
> > > the way: https://www.google.com/search?q=karaf+bnd).
> > >
> > > I've read the topic and was happy to see that Guillaume asked to
> > fill Jira
> > > issue.
> > > Then I've read with interest that JB is just "building the new
> > SNAPSHOT to
> > > test if the couple of issues".
> > > And then I navigated to the issue created by dleangen
> > > (https://issues.apache.org/jira/browse/KARAF-4160) just to see
> > that it's
> > > status is "Won't fix"...
> > >
> > > Anyway - does anybody on this group already figured it out how to
> > join Karaf
> > > and Bnd to play nicely together?
> > >
> > > Kind regards,
> > > Kamil
> > >
> > >
> > >
> > > --
> > > Sent from:
> http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> > >
> >
> > --
> > 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 - http://www.talend.com
>

Re: Bndtools & Karaf : the right way

2019-02-14 Thread Christian Schneider

The new maven build in bndtools is now a plain maven build.
Of course the bndtools examples favour the bnd-maven-plugin instead of the
maven-bundle-plugin but that is more like left and right twix :-)

The only real difference is how the bundles are then assembled into a
runable application.

There bndtools uses a bndrun file which points to a repository (based on
maven now) and requirements. The output is a runnable jar.

For karaf you create a feature with your bundles and dependencies typically
as feature dependencies. Then in a second step you can also have a karaf
custom distro to create a complete server (application).

So it is now perfectly possible to produce a bndtools based assembly and a
karaf feature and optionally a custom distro in the same build.

The only sad thing is that the deployment descriptions are not yet
compatible. As both karaf and bndtools use a bundle repository under the
hood I think this can be improved.

Christian

Am Do., 14. Feb. 2019 um 13:46 Uhr schrieb Jean-Baptiste Onofré <
j...@nanthrax.net>:

> Hi Ray,
>
> does it mean that bundle can be created in bndtools, then upload in a
> Maven repository, and installed in Karaf ?
> Maybe the only missing piece is that bndtools generate a features XML to
> have a complete story.
>
> Regards
> JB
>
> On 14/02/2019 13:44, Raymond Auge wrote:
> > Perhaps it would be better, rather than switching to the BND Workspace
> > model to simply use the BND/Bndtools Maven/m2e support. It's very good
> > now and has parity in large part with the BND Workspace. The upcoming
> > release especially should break lots of barriers.
> >
> > Just a suggestion.
> >
> > - Ray
> >
> > On Thu, Feb 14, 2019, 07:37 Jean-Baptiste Onofré  >  wrote:
> >
> > Hi,
> >
> > We didn't move forward a lot. I remember there was some discussion to
> > have a "Karaf exporter" in bndtools and I proposed my help on this.
> > I didn't move forward yet.
> >
> > Do you already know what you have in mind (if you could describe the
> use
> > case, that would be great) ?
> >
> > Regards
> > JB
> >
> > On 14/02/2019 13:20, kamilantlgc wrote:
> > > Dear Karaf User group,
> > >
> > > I have stumbled upon the exact problem - how to join Karaf and
> > Bndtools
> > > together "the right way" (this conversation is the first result in
> > Google by
> > > the way: https://www.google.com/search?q=karaf+bnd).
> > >
> > > I've read the topic and was happy to see that Guillaume asked to
> > fill Jira
> > > issue.
> > > Then I've read with interest that JB is just "building the new
> > SNAPSHOT to
> > > test if the couple of issues".
> > > And then I navigated to the issue created by dleangen
> > > (https://issues.apache.org/jira/browse/KARAF-4160) just to see
> > that it's
> > > status is "Won't fix"...
> > >
> > > Anyway - does anybody on this group already figured it out how to
> > join Karaf
> > > and Bnd to play nicely together?
> > >
> > > Kind regards,
> > > Kamil
> > >
> > >
> > >
> > > --
> > > Sent from:
> http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> > >
> >
> > --
> > 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 - http://www.talend.com
>


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

Computer Scientist
http://www.adobe.com

Re: Bndtools & Karaf : the right way

Hi Ray,

does it mean that bundle can be created in bndtools, then upload in a
Maven repository, and installed in Karaf ?
Maybe the only missing piece is that bndtools generate a features XML to
have a complete story.

Regards
JB

On 14/02/2019 13:44, Raymond Auge wrote:
> Perhaps it would be better, rather than switching to the BND Workspace
> model to simply use the BND/Bndtools Maven/m2e support. It's very good
> now and has parity in large part with the BND Workspace. The upcoming
> release especially should break lots of barriers.
> 
> Just a suggestion.
> 
> - Ray
> 
> On Thu, Feb 14, 2019, 07:37 Jean-Baptiste Onofré   wrote:
> 
> Hi,
> 
> We didn't move forward a lot. I remember there was some discussion to
> have a "Karaf exporter" in bndtools and I proposed my help on this.
> I didn't move forward yet.
> 
> Do you already know what you have in mind (if you could describe the use
> case, that would be great) ?
> 
> Regards
> JB
> 
> On 14/02/2019 13:20, kamilantlgc wrote:
> > Dear Karaf User group,
> >
> > I have stumbled upon the exact problem - how to join Karaf and
> Bndtools
> > together "the right way" (this conversation is the first result in
> Google by
> > the way: https://www.google.com/search?q=karaf+bnd).
> >
> > I've read the topic and was happy to see that Guillaume asked to
> fill Jira
> > issue.
> > Then I've read with interest that JB is just "building the new
> SNAPSHOT to
> > test if the couple of issues".
> > And then I navigated to the issue created by dleangen
> > (https://issues.apache.org/jira/browse/KARAF-4160) just to see
> that it's
> > status is "Won't fix"...
> >
> > Anyway - does anybody on this group already figured it out how to
> join Karaf
> > and Bnd to play nicely together?
> >
> > Kind regards,
> > Kamil
> >
> >
> >
> > --
> > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> >
> 
> -- 
> 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 - http://www.talend.com

Re: Bndtools & Karaf : the right way

2019-02-14 Thread Raymond Auge

Perhaps it would be better, rather than switching to the BND Workspace
model to simply use the BND/Bndtools Maven/m2e support. It's very good now
and has parity in large part with the BND Workspace. The upcoming release
especially should break lots of barriers.

Just a suggestion.

- Ray

On Thu, Feb 14, 2019, 07:37 Jean-Baptiste Onofré  Hi,
>
> We didn't move forward a lot. I remember there was some discussion to
> have a "Karaf exporter" in bndtools and I proposed my help on this.
> I didn't move forward yet.
>
> Do you already know what you have in mind (if you could describe the use
> case, that would be great) ?
>
> Regards
> JB
>
> On 14/02/2019 13:20, kamilantlgc wrote:
> > Dear Karaf User group,
> >
> > I have stumbled upon the exact problem - how to join Karaf and Bndtools
> > together "the right way" (this conversation is the first result in
> Google by
> > the way: https://www.google.com/search?q=karaf+bnd).
> >
> > I've read the topic and was happy to see that Guillaume asked to fill
> Jira
> > issue.
> > Then I've read with interest that JB is just "building the new SNAPSHOT
> to
> > test if the couple of issues".
> > And then I navigated to the issue created by dleangen
> > (https://issues.apache.org/jira/browse/KARAF-4160) just to see that it's
> > status is "Won't fix"...
> >
> > Anyway - does anybody on this group already figured it out how to join
> Karaf
> > and Bnd to play nicely together?
> >
> > Kind regards,
> > Kamil
> >
> >
> >
> > --
> > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Bndtools & Karaf : the right way

Hi,

We didn't move forward a lot. I remember there was some discussion to
have a "Karaf exporter" in bndtools and I proposed my help on this.
I didn't move forward yet.

Do you already know what you have in mind (if you could describe the use
case, that would be great) ?

Regards
JB

On 14/02/2019 13:20, kamilantlgc wrote:
> Dear Karaf User group,
> 
> I have stumbled upon the exact problem - how to join Karaf and Bndtools
> together "the right way" (this conversation is the first result in Google by
> the way: https://www.google.com/search?q=karaf+bnd).
> 
> I've read the topic and was happy to see that Guillaume asked to fill Jira
> issue.
> Then I've read with interest that JB is just "building the new SNAPSHOT to
> test if the couple of issues".
> And then I navigated to the issue created by dleangen
> (https://issues.apache.org/jira/browse/KARAF-4160) just to see that it's
> status is "Won't fix"...
> 
> Anyway - does anybody on this group already figured it out how to join Karaf
> and Bnd to play nicely together?
> 
> Kind regards,
> Kamil
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

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

Re: Bndtools & Karaf : the right way

2019-02-14 Thread kamilantlgc

Dear Karaf User group,

I have stumbled upon the exact problem - how to join Karaf and Bndtools
together "the right way" (this conversation is the first result in Google by
the way: https://www.google.com/search?q=karaf+bnd).

I've read the topic and was happy to see that Guillaume asked to fill Jira
issue.
Then I've read with interest that JB is just "building the new SNAPSHOT to
test if the couple of issues".
And then I navigated to the issue created by dleangen
(https://issues.apache.org/jira/browse/KARAF-4160) just to see that it's
status is "Won't fix"...

Anyway - does anybody on this group already figured it out how to join Karaf
and Bnd to play nicely together?

Kind regards,
Kamil



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Bndtools & Karaf : the right way

2015-12-03 Thread David Leangen

> You are correct a plain feature generation out of the resolved bundles would 
> create this result.
> 
> One way to make it easier is if we provide an index for all or at least the 
> basic karaf features per karaf version. You could then add this index to you 
> bndtools workspace and have a
> better resolution already at build time.

Ok, thank you.

> I think if you want to do the full resolution in bndtools (application mode) 
> this is the best way to go.

Hehe. Actually, I have been advocating NOT doing this at build time, so this is 
not really what I want to do, but this is the direction everybody else seems to 
want to go. ;-)

I would prefer to generate the feature “on the fly” at deployment/runtime, 
using the bundles available in the runtime system. But I am willing to live 
with a features.xml generated at build time if that is what is available to me.


Cheers,
=David

Re: Bndtools & Karaf : the right way

2015-12-03 Thread Jean-Baptiste Onofré


It depends the requirements and the way it's generated.

Karaf feature address this use case thanks to dependency/prerequisite flag.

Regards
JB

On 12/03/2015 10:40 AM, David Leangen wrote:


Hi,


By the way, bndtools does have a concept of a deployment descriptor
(bndrun). All it is, really, is just an index of the resolved
bundles, i.e. the bundles that are available in the workspace, and
are therefore available to the runtime. The list is simply the output
of the resolve operation, nothing more. This could easily be done at
runtime as well.

The result of the resolve in bndtools is not the list of bundles in
the workspace. It is the list of the bundles to be installed.


Yes, that is exactly what I meant, but that the list of bundles is taken
from the bundles that are available in the workspace. The resolved
bundles are only those that are available (in the workspace) at the time
of resolution.

Please correct me if I am mistaken, but won’t something strange like the
following happen?

Suppose that my workspace has felix scr v2.2.3 (or whatever).
Suppose that Karaf has felix scr v2.1.2 (for instance)

I the build-time resolution uses only what is available in my workspace
at the time, then my features.xml will contain felix scr v2.2.3. So,
when I want to run in Karaf, which only has the older version 2.1.2, I
will need to pull in the newer version. Now I have 2 versions of scr
running in my system. Now imagine this for all such bundles, and the
runtime system becomes a big mess, and the whole point of
componentization gets lost.

Or am I misunderstanding how this works?


Cheers,
=David



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

Re: Bndtools & Karaf : the right way

2015-12-03 Thread Guillaume Nodet

And version ranges.
That's why it's difficult to rely solely on feature generation, unless you
can actually have those requirements formalised correctly, i.e. with
correct version ranges

2015-12-03 11:06 GMT+01:00 Jean-Baptiste Onofré :

> It depends the requirements and the way it's generated.
>
> Karaf feature address this use case thanks to dependency/prerequisite flag.
>
> Regards
> JB
>
>
> On 12/03/2015 10:40 AM, David Leangen wrote:
>
>>
>> Hi,
>>
>> By the way, bndtools does have a concept of a deployment descriptor
 (bndrun). All it is, really, is just an index of the resolved
 bundles, i.e. the bundles that are available in the workspace, and
 are therefore available to the runtime. The list is simply the output
 of the resolve operation, nothing more. This could easily be done at
 runtime as well.

>>> The result of the resolve in bndtools is not the list of bundles in
>>> the workspace. It is the list of the bundles to be installed.
>>>
>>
>> Yes, that is exactly what I meant, but that the list of bundles is taken
>> from the bundles that are available in the workspace. The resolved
>> bundles are only those that are available (in the workspace) at the time
>> of resolution.
>>
>> Please correct me if I am mistaken, but won’t something strange like the
>> following happen?
>>
>> Suppose that my workspace has felix scr v2.2.3 (or whatever).
>> Suppose that Karaf has felix scr v2.1.2 (for instance)
>>
>> I the build-time resolution uses only what is available in my workspace
>> at the time, then my features.xml will contain felix scr v2.2.3. So,
>> when I want to run in Karaf, which only has the older version 2.1.2, I
>> will need to pull in the newer version. Now I have 2 versions of scr
>> running in my system. Now imagine this for all such bundles, and the
>> runtime system becomes a big mess, and the whole point of
>> componentization gets lost.
>>
>> Or am I misunderstanding how this works?
>>
>>
>> Cheers,
>> =David
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Bndtools & Karaf : the right way

2015-12-03 Thread David Leangen


Hi,

>> By the way, bndtools does have a concept of a deployment descriptor 
>> (bndrun). All it is, really, is just an index of the resolved bundles, i.e. 
>> the bundles that are available in the workspace, and are therefore available 
>> to the runtime. The list is simply the output of the resolve operation, 
>> nothing more. This could easily be done at runtime as well.
> The result of the resolve in bndtools is not the list of bundles in the 
> workspace. It is the list of the bundles to be installed.

Yes, that is exactly what I meant, but that the list of bundles is taken from 
the bundles that are available in the workspace. The resolved bundles are only 
those that are available (in the workspace) at the time of resolution.

Please correct me if I am mistaken, but won’t something strange like the 
following happen?

Suppose that my workspace has felix scr v2.2.3 (or whatever).
Suppose that Karaf has felix scr v2.1.2 (for instance)

I the build-time resolution uses only what is available in my workspace at the 
time, then my features.xml will contain felix scr v2.2.3. So, when I want to 
run in Karaf, which only has the older version 2.1.2, I will need to pull in 
the newer version. Now I have 2 versions of scr running in my system. Now 
imagine this for all such bundles, and the runtime system becomes a big mess, 
and the whole point of componentization gets lost.

Or am I misunderstanding how this works?


Cheers,
=David

Re: Bndtools & Karaf : the right way

As a first step, as said in another e-mail, I would start with a 
"bndtools" like resource repositories that users can refer in 
features.xml or global resource repositories.


For "long term", it would great to have bndtools generate feature IMHO.

Regards
JB

On 12/02/2015 04:54 PM, Christian Schneider wrote:

Am 02.12.2015 um 15:51 schrieb Guillaume Nodet:



Remember resource repositories can also point to other resource
repositories.

Interesting. I did not know this. That makes it a lot easier of course.


I read in the bndtools doc that it support multiple kind of
repositories.  Can't we just add support for feature repositories ?

It could work. Would we simply add all the bundles in the feature
repository as an index?
I think one issue might be that a feature repository does not contain
the OSGi metadata. So we would need to
create it on the fly and probably cache it.

One other approach would be a maven plugin to create an OBR index from a
feature repository. So the result would directly work in bndtools.
Probably this would be the simplest way to bring a lot of the karaf
features into bndtools for development.

For short term it could help to be able to use existing feature
repositories. For long term I really like the idea to back feature
repositories with an index.
It makes the individual features and the whole feature creation process
a lot simpler. So probably it makes sense to follow both paths.


What we would need is the input that was given to the bndtooling
during resolution / validation.
If we have this, we could certainly have a successful resolution too.
Tough having a list of bundles, i.e. the output of the resolution
would work too.

Yes I think both approaches could have their place.

For the application mode the fully resolved list of bundles could be
great. We could then even start a karaf without the feature service and
use startup.properties to list the bundles.
Another approach would be to create a feature from the resolved bundle
list.
In both cases a problem is that karaf already starts with some bundles.
So for the first approach we would need to somehow add these bundles
either already in bndtools or later.
For the second approach we would probably want to remove the initial
bundles from the feature. Maybe they could also just stay there .. not
sure though.

Christian



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

Re: Bndtools & Karaf : the right way

2015-12-02 Thread Guillaume Nodet

2015-12-02 16:54 GMT+01:00 Christian Schneider :

> Am 02.12.2015 um 15:51 schrieb Guillaume Nodet:
>
>>
>>
>> Remember resource repositories can also point to other resource
>> repositories.
>>
> Interesting. I did not know this. That makes it a lot easier of course.
>
>>
>> I read in the bndtools doc that it support multiple kind of
>> repositories.  Can't we just add support for feature repositories ?
>>
> It could work. Would we simply add all the bundles in the feature
> repository as an index?
> I think one issue might be that a feature repository does not contain the
> OSGi metadata. So we would need to
> create it on the fly and probably cache it.
>

If we simply reuse the code in features-core from bndtools, this would not
really be necessary to cache anything.
Karaf does not cache those when they are built before a resolution, and I
don't think it's necessary to do so.


>
> One other approach would be a maven plugin to create an OBR index from a
> feature repository. So the result would directly work in bndtools.
> Probably this would be the simplest way to bring a lot of the karaf
> features into bndtools for development.
>
> For short term it could help to be able to use existing feature
> repositories. For long term I really like the idea to back feature
> repositories with an index.
> It makes the individual features and the whole feature creation process a
> lot simpler. So probably it makes sense to follow both paths.


This made me think about one problem with using repositories.  For example
in aries, we release bundles individually as needed.  This would make the
creation of an R5 repository much more complicated (and still does not
remove the need for the features definition), while simply generating the
features is much easier.

I wonder how the R5 repository generation is supposed to fit in a release
model when developing with bndtools.  Unless they don't have any answer
yet.  If the idea is to use a single big repository, then that would be
very problematic.

Btw, I've just committed the fix for relative resource uris and support for
 in the features repositories.
Feel free to experiment !


>
>
>> What we would need is the input that was given to the bndtooling during
>> resolution / validation.
>> If we have this, we could certainly have a successful resolution too.
>> Tough having a list of bundles, i.e. the output of the resolution would
>> work too.
>>
> Yes I think both approaches could have their place.
>
> For the application mode the fully resolved list of bundles could be
> great. We could then even start a karaf without the feature service and use
> startup.properties to list the bundles.
> Another approach would be to create a feature from the resolved bundle
> list.
> In both cases a problem is that karaf already starts with some bundles. So
> for the first approach we would need to somehow add these bundles either
> already in bndtools or later.
> For the second approach we would probably want to remove the initial
> bundles from the feature. Maybe they could also just stay there .. not sure
> though.
>
> Christian
>
>

Re: Bndtools & Karaf : the right way

I'm just building the new SNAPSHOT to test if the couple of issues I saw 
are now fixed ;)


I keep you posted.

Thanks !
Regards
JB

On 12/02/2015 05:11 PM, Guillaume Nodet wrote:



2015-12-02 16:54 GMT+01:00 Christian Schneider >:

Am 02.12.2015 um 15:51 schrieb Guillaume Nodet:



Remember resource repositories can also point to other resource
repositories.

Interesting. I did not know this. That makes it a lot easier of course.


I read in the bndtools doc that it support multiple kind of
repositories.  Can't we just add support for feature repositories ?

It could work. Would we simply add all the bundles in the feature
repository as an index?
I think one issue might be that a feature repository does not
contain the OSGi metadata. So we would need to
create it on the fly and probably cache it.


If we simply reuse the code in features-core from bndtools, this would
not really be necessary to cache anything.
Karaf does not cache those when they are built before a resolution, and
I don't think it's necessary to do so.


One other approach would be a maven plugin to create an OBR index
from a feature repository. So the result would directly work in
bndtools.
Probably this would be the simplest way to bring a lot of the karaf
features into bndtools for development.

For short term it could help to be able to use existing feature
repositories. For long term I really like the idea to back feature
repositories with an index.
It makes the individual features and the whole feature creation
process a lot simpler. So probably it makes sense to follow both paths.


This made me think about one problem with using repositories.  For
example in aries, we release bundles individually as needed.  This would
make the creation of an R5 repository much more complicated (and still
does not remove the need for the features definition), while simply
generating the features is much easier.

I wonder how the R5 repository generation is supposed to fit in a
release model when developing with bndtools.  Unless they don't have any
answer yet.  If the idea is to use a single big repository, then that
would be very problematic.

Btw, I've just committed the fix for relative resource uris and support
for  in the features repositories.
Feel free to experiment !



What we would need is the input that was given to the bndtooling
during resolution / validation.
If we have this, we could certainly have a successful resolution
too.
Tough having a list of bundles, i.e. the output of the
resolution would work too.

Yes I think both approaches could have their place.

For the application mode the fully resolved list of bundles could be
great. We could then even start a karaf without the feature service
and use startup.properties to list the bundles.
Another approach would be to create a feature from the resolved
bundle list.
In both cases a problem is that karaf already starts with some
bundles. So for the first approach we would need to somehow add
these bundles either already in bndtools or later.
For the second approach we would probably want to remove the initial
bundles from the feature. Maybe they could also just stay there ..
not sure though.

Christian




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

Re: Bndtools & Karaf : the right way


Am 02.12.2015 um 15:51 schrieb Guillaume Nodet:



Remember resource repositories can also point to other resource 
repositories.

Interesting. I did not know this. That makes it a lot easier of course.


I read in the bndtools doc that it support multiple kind of 
repositories.  Can't we just add support for feature repositories ?
It could work. Would we simply add all the bundles in the feature 
repository as an index?
I think one issue might be that a feature repository does not contain 
the OSGi metadata. So we would need to

create it on the fly and probably cache it.

One other approach would be a maven plugin to create an OBR index from a 
feature repository. So the result would directly work in bndtools.
Probably this would be the simplest way to bring a lot of the karaf 
features into bndtools for development.


For short term it could help to be able to use existing feature 
repositories. For long term I really like the idea to back feature 
repositories with an index.
It makes the individual features and the whole feature creation process 
a lot simpler. So probably it makes sense to follow both paths.


What we would need is the input that was given to the bndtooling 
during resolution / validation.

If we have this, we could certainly have a successful resolution too.
Tough having a list of bundles, i.e. the output of the resolution 
would work too.

Yes I think both approaches could have their place.

For the application mode the fully resolved list of bundles could be 
great. We could then even start a karaf without the feature service and 
use startup.properties to list the bundles.
Another approach would be to create a feature from the resolved bundle 
list.
In both cases a problem is that karaf already starts with some bundles. 
So for the first approach we would need to somehow add these bundles 
either already in bndtools or later.
For the second approach we would probably want to remove the initial 
bundles from the feature. Maybe they could also just stay there .. not 
sure though.


Christian

Re: Bndtools & Karaf : the right way


> My understanding is that, as I explained in my earlier mail, you don't need 
> features at all.
> If you have an "application bundle" and the xml repository, that should be 
> enough, you don't have to wrap them.
> 
> Could you please raise a JIRA and attach the artefacts needed to "reproduce" 
> the use case ? I.e. maybe a zip containing the xml repository and the 
> bundles, including the application bundle.
> I'll investigate to make sure you can deploy it easily.

JIRA raised:

  https://issues.apache.org/jira/browse/KARAF-4160


Cheers,
=David

Re: Bndtools & Karaf : the right way

2015-12-02 Thread Guillaume Nodet

2015-12-02 7:06 GMT+01:00 dleangen :

> Hi,
>
>
> Guillaume Nodet-2 wrote
> >>>Anyway, once I'm given a repository and a set of bundles to look at, i'm
> willing to look at it.
>
>
> dleangen wrote
> >>Cool! Thank you very much!
> >>
> >>I will work on that as soon as I can. :-)
>
> I have created a sample bndtools (enRoute) workspace on github:
>
>   https://github.com/dleangen/org.apache.karaf.demos.enroute
>
>
> Although quite simplistic, hopefully it is representative of what happens
> in
> a typical enRoute workspace. The workspace gets released as a unit in the
> form of an OBR. To me, this “unit” is clearly homologous to a Karaf
> Feature,
> or at least very synergetic. The objective is in fact to take the released
> OBR, which is plain and simple OSGi, and transform it into a Feature on the
> fly.
>
>
> The “driver” or “application” bundle is
> org.apache.karaf.demos.enroute.application. The EnrouteApplication class
> pulls in all the required dependencies. The mechanism is to annotate the
> class, and bndtools uses the information in the annotations to write the
> requirements in the manifest. All Karaf would need to do is wrap this
> bundle, and in theory all the requirements (if available) should get
> resolved.
>
> I’m still grappling a bit with what to do about configurations with regards
> to features, but FYI I also included a simple configuration in the "enRoute
> Way” as well. You can see this in the “unrelated” bundle, which also
> happens
> to get pulled into the “application”. (I am not advocating that this
> _should_ be the right or only way to pull in a dependency or a
> configuration, just showing that it _can_ be done, and is very easy to do.)
>
> Once the code was ready, I performed a “release”, which creates an OBR.
> This
> is saved in the cnf/release directory, which I also committed to the same
> project in github. If you look at the index.xml file, you will notice that
> the application bundle indeed provides the following capability:
>
> 
>   
>   
>   
>   
> 
>
> As you can probably imagine, it would be very easy to write a parser to
> scan
> for this “feature” and create one in runtime. In fact, I already created a
> parser (was very easy to do indeed), but got blocked because currently
> Karaf
> won’t let me use this info to create a Feature in runtime, as it expects an
> xml file instead.
>

So i've just experimented a bit with this repository.
I've added the following repository to karaf which could easily be
generated.

http://karaf.apache.org/xmlns/features/v1.4.0;
name="enroute-demo">
file:///Users/gnodet/work/tmp/org.apache.karaf.demos.enroute/cnf/release/index.xml

karaf.identity;filter:="((karaf.identity=enroute-demo)(type=karaf.feature))"



After having fixed a few problems in Karaf, I was at a point where I
couldn't deploy the feature, because the above feature is not transitively
closed.  It requires 2 extenders (osgi.component
and osgi.enroute.configurer), but those are not provided in the xml.
I suppose the information is somewhat given from the list below:
https://github.com/dleangen/org.apache.karaf.demos.enroute/blob/master/org.apache.karaf.demos.enroute.application/org.apache.karaf.demos.enroute.bndrun#L11-L22

But those informations should appear somewhere, else you can't figure what
to deploy in order to solve those requirements.

Anyway, I've removed the enrolee extender requirement from the xml,
deployed scr, and finally got the application deployed (but the bundle
application which can not be resolved at runtime because of the missing
extender).

My main worry now is about those un satisfied requirements.
If the generated xml repository only contains the bundles that you are
writing, we need a way to give a list of bundles that will actually solve
the requirements that are not satisfied by the generated bundles (such as
the 2 extenders above), but it could be different requirements on packages,
services, etc...


>
> Barring any suggested improvements, then, it seems to me that the only
> things to decide on to make this nice process work are:
>
>  1. Whether or not the namespace etc. should be standardised in Karaf
>

 2. If so, what this standardisation should be, and create a corresponding
> parser
>  3. How to get a feature working in runtime without requiring the use of a
> features.xml file
>
> Please let me know if I can provide any more information. Hopefully this
> gives a better idea of what could be done. :-)
>
>
> Cheers,
> =David
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Bndtools-Karaf-the-right-way-tp4043765p4043974.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>

Re: Bndtools & Karaf : the right way

Did it come over like this? That was not my intention. I am sometimes 
not so good in showing my intentions when drifting into technical 
discussions.


I only do not like the way the karaf commands are designed today. I very 
much like the way they work and help users to have a great experience 
with karaf.

I simply hope we can improve some design in karaf to make it even better.

I also very much like karaf as a server platform. What I am worried is 
when karaf has designs that need people to go karaf exclusively. Like 
with the commands.
I would like to have a command style that works inside and outside 
karaf. So projects that implement commands can cover a larger set of 
possible deployments.
Guillaume told me that he used the improved gogo commands mainly outside 
OSGi. I think this is great.  Ideally I would like projects to write one 
set of commands
that run in karaf, standalone bndtools applications, eclipse RCP, and 
even outside OSGi. This will maximize the effect for the whole OSGi 
community but also  make more

projects write commands. So I hope karaf would benefit a lot too.

I also hope to unite the communities of karaf with other communities. 
OSGi is too small to partition it even further. Today we have at least 
three communities. Karaf, OSGi alliance / bndtools, Eclipse.
This is really a bad thing. If every project of these communities would 
run on all the plaforms OSGi would be much stronger and in effect karaf 
would be stronger.


It is just that I think karaf has developed in a way that made it a bit 
incompatible with other projects. We need to correct this to bring the 
communities together.


I do not have a strong opinion about cave as I have not used it a lot. 
My main issue is that I think a solution that can achieve widespread use 
probably
can not be based on a server you have to install. This is a barrier that 
many users will not take. I would like the indexed approach to be the 
standard for karaf features
at some point. So it needs to have a very low barrier for users to start 
with it.
This is why I am pushing an index solution that can just reuse the maven 
repository as the server as this allows that everyone uses it.


I hope that could make my intentions a bit clearer.

Christian



On 02.12.2015 08:08, Jean-Baptiste Onofré wrote:
So, let me summarize: you don't like the Karaf commands, you don't 
like Cave. So basically, you are not a very Karaf supporter ;)


Too bad ;)

Regards
JB


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

Open Source Architect
http://www.talend.com

Re: Bndtools & Karaf : the right way


Hi Guillaume,

Thank you very much for looking into this so quickly!


> So i've just experimented a bit with this repository.
> I've added the following repository to karaf which could easily be generated.
> 
> http://karaf.apache.org/xmlns/features/v1.4.0 
> " 
>   name="enroute-demo">
>   
>   
> file:///Users/gnodet/work/tmp/org.apache.karaf.demos.enroute/cnf/release/index.xml
>   
>   
>   
> karaf.identity;filter:="((karaf.identity=enroute-demo)(type=karaf.feature))"
>   
>   
> 

What do you mean by “generated”? Do you mind providing a few more details?


> After having fixed a few problems in Karaf, I was at a point where I couldn't 
> deploy the feature, because the above feature is not transitively closed.  It 
> requires 2 extenders (osgi.component and osgi.enroute.configurer), but those 
> are not provided in the xml.
> I suppose the information is somewhat given from the list below:
> https://github.com/dleangen/org.apache.karaf.demos.enroute/blob/master/org.apache.karaf.demos.enroute.application/org.apache.karaf.demos.enroute.bndrun#L11-L22
>  
> 
> 
> But those informations should appear somewhere, else you can't figure what to 
> deploy in order to solve those requirements.

Hmmm…

In enRoute, these just get resolved, so I have never really thought about it.

> My main worry now is about those un satisfied requirements.
> If the generated xml repository only contains the bundles that you are 
> writing, we need a way to give a list of bundles that will actually solve the 
> requirements that are not satisfied by the generated bundles (such as the 2 
> extenders above), but it could be different requirements on packages, 
> services, etc…

> Maybe it could be a standard "enRoute" repository that we can provide as 
>  or global resource repository ?

I personally think this is a great idea! :-)


Cheers,
=David

Re: Bndtools & Karaf : the right way

>> Try with feature:requirement-add 
>> ‘requirement:osgi.identity;osgi.identity=my.bundle;type=osgi.bundle'
> 
> Still trying. I must be doing something wrong… :-(

I don’t know if my expectations are correct or not, but I was expecting that 
requirement-add would also pull in all the declared (via requirements) 
dependencies. However, that is unfortunately not the case. From the command 
line, I need to manually add all the dependencies, in the right order, one by 
one. Since this is quite tedious, my guess is that something is not working as 
it should.

I have added that information to the JIRA as well. :-)

  https://issues.apache.org/jira/browse/KARAF-4161 




Cheers,
=David

Re: Bndtools & Karaf : the right way


We are aligned !

My point is that we just have to go in the right direction, and not just 
"follow the fashion".


For instance, our Karaf features concept is very convenient, and I don't 
see lot of values in the bndtools application compare to features 
(actually, there's some missing parts like configuration, etc). Of 
course, we can have better integration.


We can drive more the specification for sure.

Regards
JB

On 12/02/2015 10:59 AM, Christian Schneider wrote:

Did it come over like this? That was not my intention. I am sometimes
not so good in showing my intentions when drifting into technical
discussions.

I only do not like the way the karaf commands are designed today. I very
much like the way they work and help users to have a great experience
with karaf.
I simply hope we can improve some design in karaf to make it even better.

I also very much like karaf as a server platform. What I am worried is
when karaf has designs that need people to go karaf exclusively. Like
with the commands.
I would like to have a command style that works inside and outside
karaf. So projects that implement commands can cover a larger set of
possible deployments.
Guillaume told me that he used the improved gogo commands mainly outside
OSGi. I think this is great.  Ideally I would like projects to write one
set of commands
that run in karaf, standalone bndtools applications, eclipse RCP, and
even outside OSGi. This will maximize the effect for the whole OSGi
community but also  make more
projects write commands. So I hope karaf would benefit a lot too.

I also hope to unite the communities of karaf with other communities.
OSGi is too small to partition it even further. Today we have at least
three communities. Karaf, OSGi alliance / bndtools, Eclipse.
This is really a bad thing. If every project of these communities would
run on all the plaforms OSGi would be much stronger and in effect karaf
would be stronger.

It is just that I think karaf has developed in a way that made it a bit
incompatible with other projects. We need to correct this to bring the
communities together.

I do not have a strong opinion about cave as I have not used it a lot.
My main issue is that I think a solution that can achieve widespread use
probably
can not be based on a server you have to install. This is a barrier that
many users will not take. I would like the indexed approach to be the
standard for karaf features
at some point. So it needs to have a very low barrier for users to start
with it.
This is why I am pushing an index solution that can just reuse the maven
repository as the server as this allows that everyone uses it.

I hope that could make my intentions a bit clearer.

Christian



On 02.12.2015 08:08, Jean-Baptiste Onofré wrote:

So, let me summarize: you don't like the Karaf commands, you don't
like Cave. So basically, you are not a very Karaf supporter ;)

Too bad ;)

Regards
JB




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

Re: Bndtools & Karaf : the right way

2015-12-02 Thread Guillaume Nodet

2015-12-02 11:04 GMT+01:00 David Leangen :

>
> Hi Guillaume,
>
> Thank you very much for looking into this so quickly!
>
>
> So i've just experimented a bit with this repository.
> I've added the following repository to karaf which could easily be
> generated.
>
> http://karaf.apache.org/xmlns/features/v1.4.0;
> name="enroute-demo">
> 
> file:///Users/gnodet/work/tmp/org.apache.karaf.demos.enroute/cnf/release/index.xml
> 
>
> karaf.identity;filter:="((karaf.identity=enroute-demo)(type=karaf.feature))"
> 
> 
>
>
> What do you mean by “generated”? Do you mind providing a few more details?
>

What could  be done is a command that would create the features repository,
given the resource xml repository generated by bnd.  It's just about
parsing the repository, finding the "application" bundles, and create the
above blob of xml.  Nothing very difficult from a technical pov.

Again, the real problem is that I think those repositories should be
transitively closed, i.e. they should contain everything needed to actually
install and run the application.  It's currently not the case, as it seems
that bnd will only generate the xml repository for the bundles in the
project, not their dependencies.

I think we end up with really two different things here: bndtools is
certainly a nice toolchain to build OSGi bundles.  It does not look like a
runtime deployment mechanism.  And that's what karaf features are.
They should contain enough information for the whole application to be
deployed, eventually the container to be modified (karaf provides
"profiles" which may contain non ConfigAdmin configuration, libraries to
add to the class path, etc...)
It's one thing to generate the bundles, it's a different one to deploy them
in a system, manage the lifecycle of the applications, upgrade
applications, etc...

The more I think about it, the less I think it's a good idea to have too
much support for applications.  It will lack support for some features at a
later point, and those have been already solved and would only support
simple use cases.
Imho, if you plan on deploying your bundles in Karaf, you should generate a
feature inside your build.  For the above, it's just a matter of adding a
dependency on the felix scr feature and a bundle dependency on the other
extender.

Anyway, once the 4.0.x branch has been created, I'll push what I have so
far to master, that will allow you to use the  element
inside features and fix a bunch of other problems related to deploying
resources from those repositories.


>
>
> After having fixed a few problems in Karaf, I was at a point where I
> couldn't deploy the feature, because the above feature is not transitively
> closed.  It requires 2 extenders (osgi.component
> and osgi.enroute.configurer), but those are not provided in the xml.
> I suppose the information is somewhat given from the list below:
>
> https://github.com/dleangen/org.apache.karaf.demos.enroute/blob/master/org.apache.karaf.demos.enroute.application/org.apache.karaf.demos.enroute.bndrun#L11-L22
>
> But those informations should appear somewhere, else you can't figure what
> to deploy in order to solve those requirements.
>
>
> Hmmm…
>
> In enRoute, these just get resolved, so I have never really thought about
> it.
>
> My main worry now is about those un satisfied requirements.
> If the generated xml repository only contains the bundles that you are
> writing, we need a way to give a list of bundles that will actually solve
> the requirements that are not satisfied by the generated bundles (such as
> the 2 extenders above), but it could be different requirements on packages,
> services, etc…
>
>
> Maybe it could be a standard "enRoute" repository that we can provide as
>  or global resource repository ?
>
>
> I personally think this is a great idea! :-)
>
>
> Cheers,
> =David
>
>

Re: Bndtools & Karaf : the right way


On 02.12.2015 13:34, Guillaume Nodet wrote:


What could  be done is a command that would create the features 
repository, given the resource xml repository generated by bnd.  It's 
just about parsing the repository, finding the "application" bundles, 
and create the above blob of xml.  Nothing very difficult from a 
technical pov.


Again, the real problem is that I think those repositories should be 
transitively closed, i.e. they should contain everything needed to 
actually install and run the application.  It's currently not the 
case, as it seems that bnd will only generate the xml repository for 
the bundles in the project, not their dependencies.
Fully agree about the transitive closedness of a repository. I think we 
will need a mechanism to validate this. Ideally already at build time.

Though I am not sure if each repository must be transitively closed.

For example if you would create a repository for your application but 
also use a repository for hibernate that is already provided (at some 
point) by hibernate. Then you would not want to reiterate all the 
bundles from hibernate
in your repository. So maybe we can say that a set of repositories must 
be transitively closed. We could use this concept similarly to the 
feature validation where you can give the validator maven plugin 
additional feature repos to

include.

I will talk to Tim Ward if he can maybe add such a validation in the 
bnd-indexer plugin. I think such a validation would also help projects 
that create indexes. Often such projects do not do OSGi tests and the 
validation would already give them some safety net.


I think we end up with really two different things here: bndtools is 
certainly a nice toolchain to build OSGi bundles.  It does not look 
like a runtime deployment mechanism.  And that's what karaf features are.
They should contain enough information for the whole application to be 
deployed, eventually the container to be modified (karaf provides 
"profiles" which may contain non ConfigAdmin configuration, libraries 
to add to the class path, etc...)
It's one thing to generate the bundles, it's a different one to deploy 
them in a system, manage the lifecycle of the applications, upgrade 
applications, etc...


The more I think about it, the less I think it's a good idea to have 
too much support for applications.  It will lack support for some 
features at a later point, and those have been already solved and 
would only support simple use cases.
Imho, if you plan on deploying your bundles in Karaf, you should 
generate a feature inside your build.  For the above, it's just a 
matter of adding a dependency on the felix scr feature and a bundle 
dependency on the other extender.
I also think that for the moment the best way is to create the feature 
during the build. Apart from the resource-repository element this should 
not require any enhancements in karaf.
So it would be a fast way to start and we can gather some experience 
before deciding about further enhancements.


I think it should also be possible to use the Configurer from enroute if 
you like it. As you just need to also install the extender.
So the feature file should be pretty simple. I think it would be 
absolutely possible to generate it but it would not save you a lot of 
effort.


Christian


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

Open Source Architect
http://www.talend.com

Re: Bndtools & Karaf : the right way

I agree with Christian.  element in feature, with the 
existing global resources repo property (and the commands that I gonna 
push) are good for now.


Regards
JB

On 12/02/2015 01:54 PM, Christian Schneider wrote:

On 02.12.2015 13:34, Guillaume Nodet wrote:


What could  be done is a command that would create the features
repository, given the resource xml repository generated by bnd.  It's
just about parsing the repository, finding the "application" bundles,
and create the above blob of xml.  Nothing very difficult from a
technical pov.

Again, the real problem is that I think those repositories should be
transitively closed, i.e. they should contain everything needed to
actually install and run the application.  It's currently not the
case, as it seems that bnd will only generate the xml repository for
the bundles in the project, not their dependencies.

Fully agree about the transitive closedness of a repository. I think we
will need a mechanism to validate this. Ideally already at build time.
Though I am not sure if each repository must be transitively closed.

For example if you would create a repository for your application but
also use a repository for hibernate that is already provided (at some
point) by hibernate. Then you would not want to reiterate all the
bundles from hibernate
in your repository. So maybe we can say that a set of repositories must
be transitively closed. We could use this concept similarly to the
feature validation where you can give the validator maven plugin
additional feature repos to
include.

I will talk to Tim Ward if he can maybe add such a validation in the
bnd-indexer plugin. I think such a validation would also help projects
that create indexes. Often such projects do not do OSGi tests and the
validation would already give them some safety net.


I think we end up with really two different things here: bndtools is
certainly a nice toolchain to build OSGi bundles.  It does not look
like a runtime deployment mechanism.  And that's what karaf features are.
They should contain enough information for the whole application to be
deployed, eventually the container to be modified (karaf provides
"profiles" which may contain non ConfigAdmin configuration, libraries
to add to the class path, etc...)
It's one thing to generate the bundles, it's a different one to deploy
them in a system, manage the lifecycle of the applications, upgrade
applications, etc...

The more I think about it, the less I think it's a good idea to have
too much support for applications.  It will lack support for some
features at a later point, and those have been already solved and
would only support simple use cases.
Imho, if you plan on deploying your bundles in Karaf, you should
generate a feature inside your build.  For the above, it's just a
matter of adding a dependency on the felix scr feature and a bundle
dependency on the other extender.

I also think that for the moment the best way is to create the feature
during the build. Apart from the resource-repository element this should
not require any enhancements in karaf.
So it would be a fast way to start and we can gather some experience
before deciding about further enhancements.

I think it should also be possible to use the Configurer from enroute if
you like it. As you just need to also install the extender.
So the feature file should be pretty simple. I think it would be
absolutely possible to generate it but it would not save you a lot of
effort.

Christian




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

Re: Bndtools & Karaf : the right way


Hi,

>>> What could  be done is a command that would create the features
>>> repository, given the resource xml repository generated by bnd.  It's
>>> just about parsing the repository, finding the "application" bundles,
>>> and create the above blob of xml.  Nothing very difficult from a
>>> technical pov.

Cool!


>>> Again, the real problem is that I think those repositories should be
>>> transitively closed, i.e. they should contain everything needed to
>>> actually install and run the application.  It's currently not the
>>> case, as it seems that bnd will only generate the xml repository for
>>> the bundles in the project, not their dependencies.
>> Fully agree about the transitive closedness of a repository. I think we
>> will need a mechanism to validate this. Ideally already at build time.
>> Though I am not sure if each repository must be transitively closed.

I also agree.

Actually, bndtools already has a resolution tool for this, but it is based on 
the repositories installed in the workspace. By envoking the resolution 
function, (i) the resolution is validated, and (ii) the runtime descriptor 
(bndrun) file is generated.


>> For example if you would create a repository for your application but
>> also use a repository for hibernate that is already provided (at some
>> point) by hibernate. Then you would not want to reiterate all the
>> bundles from hibernate
>> in your repository. So maybe we can say that a set of repositories must
>> be transitively closed. We could use this concept similarly to the
>> feature validation where you can give the validator maven plugin
>> additional feature repos to
>> include.

Very well explained. :-)

Or instead of giving additional feature repos, perhaps the other OBRs could be 
provided as arguments. If all the correct OBRs are provided, then the system 
becomes transitively closed.

Perhaps what is missing in enRoute is a karaf runtime integration for testing 
that everything in a bnd workspace properly resolves at runtime. If the right 
OBRs are not provided, and the system is not transitively closed, the 
resolution will throw an error. This would be a quick and easy development-time 
validation of the requirements. If a OBR-referencing “feature resolution” works 
at development time, then normally it should also work at runtime.


>>> The more I think about it, the less I think it's a good idea to have
>>> too much support for applications.  It will lack support for some
>>> features at a later point, and those have been already solved and
>>> would only support simple use cases.

I think that “application” is a misnomer, and leads to a misunderstanding of 
what the “driving” bundle is supposed to accomplish. All the “application” 
bundle does is act as the driving bundle to pull in all the requirements. It is 
actually very similar to the idea of a feature, I think. It describes all the 
requirements to get the application/unit/feature/whatever to run. It is best to 
disassociate the concept with an actual “application”. I feel that this is 
causing confusion.

By the way, bndtools does have a concept of a deployment descriptor (bndrun). 
All it is, really, is just an index of the resolved bundles, i.e. the bundles 
that are available in the workspace, and are therefore available to the 
runtime. The list is simply the output of the resolve operation, nothing more. 
This could easily be done at runtime as well.


>>> Imho, if you plan on deploying your bundles in Karaf, you should
>>> generate a feature inside your build.  For the above, it's just a
>>> matter of adding a dependency on the felix scr feature and a bundle
>>> dependency on the other extender.

The requirement is already there, so perhaps I am missing something. :-(

Do you mean that a requirement on that feature would cause the feature to be 
installed? Why would a requirement on osgi.component not be sufficient, if 
there is a bundle in an OBR that provides the capability? The enRoute resolver 
is able to pick it up.

I suppose that the idea above about referencing other OBRs would work. It seems 
to work very well in enRoute.

BTW, I am still having trouble understanding why you are advocating that the 
runtime environment should be fixed during bundle development. Perhaps it is a 
usual practice, but doesn’t it limit the component-based approach that OSGi is 
supposed to promote? Components are developed to provide services, and they are 
developed out of context. The components get composed into a dynamic runtime 
system. Seems that it is a waste of a very good opportunity to decouple bundle 
development from deployment, IMHO.

Perhaps somebody has already explained, but I would think that such decoupled 
would be a very good thing. I have bought into the OSGi vision, but coupling 
deployment to development does not seem compatible with this vision.

>> I also think that for the moment the best way is to create the feature
>> during the build. Apart from the resource-repository

Re: Bndtools & Karaf : the right way


On 02.12.2015 14:46, David Leangen wrote:



Fully agree about the transitive closedness of a repository. I think we
will need a mechanism to validate this. Ideally already at build time.
Though I am not sure if each repository must be transitively closed.

I also agree.

Actually, bndtools already has a resolution tool for this, but it is based on 
the repositories installed in the workspace. By envoking the resolution 
function, (i) the resolution is validated, and (ii) the runtime descriptor 
(bndrun) file is generated.
This is a bit of a different case. bndtools only validates that the 
requirements you list can be resolved.


What we meant is that we should also validate the whole repository. I 
think currently it could happen that some bundles in a repository can 
not be resolved.
If the repository is created during a build this could point to a 
problem. So validation would help to get a good quality for the repository.

For example if you would create a repository for your application but
also use a repository for hibernate that is already provided (at some
point) by hibernate. Then you would not want to reiterate all the
bundles from hibernate
in your repository. So maybe we can say that a set of repositories must
be transitively closed. We could use this concept similarly to the
feature validation where you can give the validator maven plugin
additional feature repos to
include.

Very well explained. :-)

Or instead of giving additional feature repos, perhaps the other OBRs could be 
provided as arguments. If all the correct OBRs are provided, then the system 
becomes transitively closed.

Exactly. There should be a validation that you can call with a list of obrs.



Perhaps what is missing in enRoute is a karaf runtime integration for testing 
that everything in a bnd workspace properly resolves at runtime. If the right 
OBRs are not provided, and the system is not transitively closed, the 
resolution will throw an error. This would be a quick and easy development-time 
validation of the requirements. If a OBR-referencing “feature resolution” works 
at development time, then normally it should also work at runtime.
As soon as we also have obr indexes for the karaf features it should be 
easier to work with this in bndtools.

The more I think about it, the less I think it's a good idea to have
too much support for applications.  It will lack support for some
features at a later point, and those have been already solved and
would only support simple use cases.

I think that “application” is a misnomer, and leads to a misunderstanding of 
what the “driving” bundle is supposed to accomplish. All the “application” 
bundle does is act as the driving bundle to pull in all the requirements. It is 
actually very similar to the idea of a feature, I think. It describes all the 
requirements to get the application/unit/feature/whatever to run. It is best to 
disassociate the concept with an actual “application”. I feel that this is 
causing confusion.

By the way, bndtools does have a concept of a deployment descriptor (bndrun). 
All it is, really, is just an index of the resolved bundles, i.e. the bundles 
that are available in the workspace, and are therefore available to the 
runtime. The list is simply the output of the resolve operation, nothing more. 
This could easily be done at runtime as well.
The result of the resolve in bndtools is not the list of bundles in the 
workspace. It is the list of the bundles to be installed.


Karaf does the same internally in the feature service. You just do not 
yet see it as we are lacking support for an obr index that backs a 
feature file. As soon as Guillaume pushes his changes it should become 
clearer what karaf can do there. Then you just add your indexes and the 
application bundle to the feature file and karaf does the resolve step 
at runtime.


Christian



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

Open Source Architect
http://www.talend.com

Re: Bndtools & Karaf : the right way

2015-12-01 Thread development

 

I can't remember and don't understand all the conversation from the
emails below but I thought that if you pulled in the new code from
Guillaume then you could make karaf and gogo more compatible. I thought
the issue was it required java8 but from my understanding the next
release of karaf after 4.0.4 was going to require java8 anyway for the
pax-web jetty 9.3 stuff. 

On 11/3/15, 2:31 PM, "Frank Langel"  wrote:

> Agreed. But which way to go a) back port the Karaf one? B) the new console 
> version by Guillaume Nodet Best Frank On 11/3/15, 2:26 PM, "David Bosschaert" 
> 

wrote:

>> I always wondered why the 'fork' of gogo that's in Karaf was never 
>> contributed back into Felix? I think that it is much better in terms of 
>> usability (completion, colours) and it would be nice if it could be used by 
>> the Felix framework as well, i.e. be shipped as the default shell 
>> implementation with the Felix download... Any thoughts? Cheers, David On 3 
>> November 2015 at 14:15, Frank Langel 

wrote:

> Awesome, I try it out On 11/3/15, 1:37 PM, "Guillaume Nodet" 
>  wrote: I've been improving JLine, Gogo Runtime and wrote 
> a new module for

JLine +

> Gogo, similar to gogo-shell, but with tighter integration. Feel free to have 
> a look at it if you want. You'll have to build 
> https://github.com/jline/jline2/tree/jline3 [1] and 
> https://github.com/gnodet/felix/tree/trunk-jline/gogo [2] Inside the gogo 
> dir, you can launch the shell using: java -cp

On 2015-12-01 14:02, Jean-Baptiste Onofré wrote: 

> Honestly, I disagree about the Karaf commands: currently Karaf commands and 
> shell are way more powerful and better than Felix gogo.
> 
> Don't be too harsh and remember that, for lot of us, Karaf brings us in OSGi, 
> shell, etc. I always remember where I come from ;)
> 
> Regards
> JB
> 
> On 12/01/2015 07:28 AM, Christian Schneider wrote:
> Am 01.12.2015 um 05:55 schrieb David Leangen: So as you see it is not the 
> build system. I would be interested how you do all the things above without 
> the maven repo. I get the feeling that you are comparing apples to smoothies. 
> The apple is the actual repository, i.e. convention as to where and how the 
> data is stored, while the smoothie is what you do with it. I think that OBR 
> is a more advanced apple than maven, but nobody has really developed the 
> smoothie yet, so maven has the better smoothie. You seem more interested in 
> the smoothie, maybe. (Ok, bad metaphor??) Since maven is so widely adopted, 
> it would be foolish to ignore. That is not what I am suggesting. However, I 
> think it would not be wise to force Karaf users into the maven world, either.
 You are right. For OSGi we need a repository with support for OSGi
metadata. Only then can we use the resolver in an efficient way. I think
an OBR like Cave is the wrong approach though. It want to index the
whole repository which does not work on the scale of maven repos
especially not for maven central. I think the nice middle ground is
using the maven indexer plugin the Tim Ward created. I plan to use this
plugin in the build process of the apache projects (per project and per
version). So for example hibernate 5.0.0 would create an index with all
the bundles it needs. This index is then stored in the maven repository
as a file. So this has two advantages. 1. The index does not have any
conflicting bundles 2. The index is small and easy to handle. So I think
this has the potential to combine the advantages of maven and obr. 

> I really like the way that Karaf has handled blueprint vs. DS. Kara itself is 
> based in part on blueprint, but I am not forced to use it. This, I do not 
> mind at all. Even when I list the current bundles, by default I don't even 
> have to look at the stuff installed behind the scenes. I was initially 
> worried about all the "stuff" getting installed, but I have relaxed a bit. 
> For Karaf commands, also at first I was not happy that it forced me to 
> decided "either or" simple gogo commands or Karaf commands. However, the 
> commands really are nice. I think somebody should push to have completes and 
> all the other nice stuff added to the OSGi spec.
 Fully agree. I was never a fan of the karaf command style. The felix
ones are much nicer in regard to OSGi services and we should bring them
en part with the karaf style and support both styles in karaf. It would
also be great to then put the enhancement into a spec. I would really
like to see commands that are then usable in karaf but also in plain
OSGi frameworks or even outside OSGi. There is no reason why all of
these must be different. Christian 

Links:
--
[1] https://github.com/jline/jline2/tree/jline3
[2] https://github.com/gnodet/felix/tree/trunk-jline/gogo

Re: Bndtools & Karaf : the right way

2015-12-01 Thread Guillaume Nodet

2015-12-01 22:24 GMT+01:00 Christian Schneider :

> I also like the karaf shell a lot. The main thing I dislike is that the
> command or better Action class is not a singleton and so it is difficult to
> provide as a service.
>

Unfortunately, there are not many ways to write command:
  * put arguments and options in fields, in which case you can't use
singletons
  * have a method (or multiple) with options / arguments as method
arguments : having lots of options can become problematic and not really
easy to write or invoke
  * have a method with an Object[] argument to hold everything

There are pros and cons for each, but there's no silver bullet.


> Felix gogo is much nicer in this regard. With the current enhancements
> from Guillaume it will be a lot nearer karaf in regard to features too.
> I am currently helping to get this on the way.
>
> So I hope we can unite the two systems again or at least make it easy for
> both to coexist in the same framework.
>
> Christian
>
>
> Am 01.12.2015 um 20:02 schrieb Jean-Baptiste Onofré:
>
>> Honestly, I disagree about the Karaf commands: currently Karaf commands
>> and shell are way more powerful and better than Felix gogo.
>>
>> Don't be too harsh and remember that, for lot of us, Karaf brings us in
>> OSGi, shell, etc. I always remember where I come from ;)
>>
>> Regards
>> JB
>>
>>
>

Re: Bndtools & Karaf : the right way

2015-12-01 Thread Christian Schneider

I also like the karaf shell a lot. The main thing I dislike is that the 
command or better Action class is not a singleton and so it is difficult 
to provide as a service.
Felix gogo is much nicer in this regard. With the current enhancements 
from Guillaume it will be a lot nearer karaf in regard to features too.

I am currently helping to get this on the way.

So I hope we can unite the two systems again or at least make it easy 
for both to coexist in the same framework.


Christian

Am 01.12.2015 um 20:02 schrieb Jean-Baptiste Onofré:
Honestly, I disagree about the Karaf commands: currently Karaf 
commands and shell are way more powerful and better than Felix gogo.


Don't be too harsh and remember that, for lot of us, Karaf brings us 
in OSGi, shell, etc. I always remember where I come from ;)


Regards
JB

Re: Bndtools & Karaf : the right way

2015-12-01 Thread development

It was the gogo shell conversation that I couldn't remember and I had
included but I think Christian and Guillaume picked up on it and seem to
be working on a way forward. I like the karaf shell. It has
autocomplete, history, coloring and several other features that the gogo
shell was missing. I think karaf and gogo shell split because one of the
libraries changed their license. I knew Guilluame was working on a new
version of the shell that used a custom version of jline that fixed the
licensing issue but there was another blocker in that the new version
required java8. Java8 should not be a problem with karaf after 4.0.4
because it is needed for the new jetty but it may still be an issue with
felix. I was hoping that if in the new karaf upgrade the karaf shell
moved to use Guillaume's new code then some of the changes could be
merged back into the gogo shell. As far as I can tell there has been
very little work on the gogo shell recently but it would be nice if that
changed. I cannot speak to the issues Christian has with the karaf shell
but they seem to have optional fixes if you are willing to accept the
draw backs. 

David Daniel 

On 2015-12-01 21:22, David Leangen wrote: 

>> I can't remember and don't understand all the conversation from the emails 
>> below
> 
> It started from a comment I made: 
> 
> For Karaf commands, also at first I was not happy that it forced me to
> decide "either or" simple gogo commands or Karaf commands. However,
> the Karaf commands really are nice. I think somebody should push to have
> completers and all the other nice stuff added to the OSGi spec.

It was in the context of "standard" vs. "non-standard" OSGi. Karaf seems
to be doing both, but for good reasons. 

There are still many holes in OSGi. Whether they are left there on
purpose to allow people the freedom to design their own solutions, or
they are there simply because nobody has developed the solution yet, I
cannot say. Karaf is clearly pushing the boundaries on the runtime
front. 

Pushing the boundaries is great, but I think we need to be careful when
things get too far. 

I really like Karaf commands, but they seem to have become
"non-standard", which is something I usually try to avoid when possible.
To me, the ideal solution is to take the great things about Karaf
commands (help system, completers...) and try to introduce them into the
OSGi spec. 

Has anybody considered this? 

Cheers, 
=David

Re: Bndtools & Karaf : the right way

2015-12-01 Thread Jean-Baptiste Onofré

So, let me summarize: you don't like the Karaf commands, you don't like 
Cave. So basically, you are not a very Karaf supporter ;)


Too bad ;)

Regards
JB

On 12/01/2015 07:28 AM, Christian Schneider wrote:



Am 01.12.2015 um 05:55 schrieb David Leangen:



So as you see it is not the build system. I would be interested how
you do all the things above without the maven repo.

I get the feeling that you are comparing apples to smoothies. The
apple is the actual repository, i.e. convention as to where and how
the data is stored, while the smoothie is what you do with it. I think
that OBR is a more advanced apple than maven, but nobody has really
developed the smoothie yet, so maven has the better smoothie. You seem
more interested in the smoothie, maybe. (Ok, bad metaphor??)

Since maven is so widely adopted, it would be foolish to ignore. That
is not what I am suggesting. However, I think it would not be wise to
force Karaf users into the maven world, either.

You are right. For OSGi we need a repository with support for OSGi
metadata. Only then can we use the resolver in an efficient way.
I think an OBR like Cave is the wrong approach though. It want to index
the whole repository which does not work on the scale of maven repos
especially not for maven central.

I think the nice middle ground is using the maven indexer plugin the Tim
Ward created. I plan to use this plugin in the build process of the
apache projects (per project and per version). So for example hibernate
5.0.0 would create an index with all the bundles it needs. This index is
then stored in the maven repository as a file.

So this has two advantages.
1. The index does not have any conflicting bundles
2. The index is small and easy to handle.

So I think this has the potential to combine the advantages of maven and
obr.


I really like the way that Karaf has handled blueprint vs. DS. Kara
itself is based in part on blueprint, but I am not forced to use it.
This, I do not mind at all. Even when I list the current bundles, by
default I don’t even have to look at the stuff installed behind the
scenes. I was initially worried about all the “stuff” getting
installed, but I have relaxed a bit.

For Karaf commands, also at first I was not happy that it forced me to
decided “either or” simple gogo commands or Karaf commands. However,
the commands really are nice. I think somebody should push to have
completes and all the other nice stuff added to the OSGi spec.

Fully agree. I was never a fan of the karaf command style. The felix
ones are much nicer in regard to OSGi services and we should bring them
en part with the karaf style and support both styles in karaf. It would
also be great to then put the enhancement into a spec.
I would really like to see commands that are then usable in karaf but
also in plain OSGi frameworks or even outside OSGi. There is no reason
why all of these must be different.

Christian



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

Re: Bndtools & Karaf : the right way

2015-12-01 Thread Jean-Baptiste Onofré

I think Christian didn't use Cave a lot. Of course, Cave can index a 
whole repository, but I can also create multiple repositories per artifact.


More over, I know jpm4j but it's another package manager: it doesn't 
really solve.


I'm using Karaf + Cave a lot (with bunch of repos) and it works fine 
(you can proxy artifact per repository, and I have a command to create 
index XML per artifact URL).


Regards
JB

On 12/02/2015 06:45 AM, David Leangen wrote:

Since maven is so widely adopted, it would be foolish to ignore. That
is not what I am suggesting. However, I think it would not be wise to
force Karaf users into the maven world, either.

You are right. For OSGi we need a repository with support for OSGi
metadata. Only then can we use the resolver in an efficient way.
I think an OBR like Cave is the wrong approach though. It want to
index the whole repository which does not work on the scale of maven
repos especially not for maven central.


Do you know JMP?

https://jpm4j.org

Perhaps this solves the problem you mention, or perhaps could provide a
little inspiration?


Cheers,
=David




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

Re: Bndtools & Karaf : the right way

2015-12-01 Thread dleangen

Hi,


Guillaume Nodet-2 wrote
>>>Anyway, once I'm given a repository and a set of bundles to look at, i'm
willing to look at it.


dleangen wrote
>>Cool! Thank you very much!
>>
>>I will work on that as soon as I can. :-)

I have created a sample bndtools (enRoute) workspace on github:

  https://github.com/dleangen/org.apache.karaf.demos.enroute


Although quite simplistic, hopefully it is representative of what happens in
a typical enRoute workspace. The workspace gets released as a unit in the
form of an OBR. To me, this “unit” is clearly homologous to a Karaf Feature,
or at least very synergetic. The objective is in fact to take the released
OBR, which is plain and simple OSGi, and transform it into a Feature on the
fly.


The “driver” or “application” bundle is
org.apache.karaf.demos.enroute.application. The EnrouteApplication class
pulls in all the required dependencies. The mechanism is to annotate the
class, and bndtools uses the information in the annotations to write the
requirements in the manifest. All Karaf would need to do is wrap this
bundle, and in theory all the requirements (if available) should get
resolved.

I’m still grappling a bit with what to do about configurations with regards
to features, but FYI I also included a simple configuration in the "enRoute
Way” as well. You can see this in the “unrelated” bundle, which also happens
to get pulled into the “application”. (I am not advocating that this
_should_ be the right or only way to pull in a dependency or a
configuration, just showing that it _can_ be done, and is very easy to do.)

Once the code was ready, I performed a “release”, which creates an OBR. This
is saved in the cnf/release directory, which I also committed to the same
project in github. If you look at the index.xml file, you will notice that
the application bundle indeed provides the following capability:


  
  
  
  


As you can probably imagine, it would be very easy to write a parser to scan
for this “feature” and create one in runtime. In fact, I already created a
parser (was very easy to do indeed), but got blocked because currently Karaf
won’t let me use this info to create a Feature in runtime, as it expects an
xml file instead.

Barring any suggested improvements, then, it seems to me that the only
things to decide on to make this nice process work are:

 1. Whether or not the namespace etc. should be standardised in Karaf
 2. If so, what this standardisation should be, and create a corresponding
parser
 3. How to get a feature working in runtime without requiring the use of a
features.xml file

Please let me know if I can provide any more information. Hopefully this
gives a better idea of what could be done. :-)


Cheers,
=David



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Bndtools-Karaf-the-right-way-tp4043765p4043974.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Bndtools & Karaf : the right way

2015-12-01 Thread David Leangen

>> Since maven is so widely adopted, it would be foolish to ignore. That is not 
>> what I am suggesting. However, I think it would not be wise to force Karaf 
>> users into the maven world, either.
> You are right. For OSGi we need a repository with support for OSGi metadata. 
> Only then can we use the resolver in an efficient way.
> I think an OBR like Cave is the wrong approach though. It want to index the 
> whole repository which does not work on the scale of maven repos 
> especially not for maven central.

Do you know JMP?

  https://jpm4j.org 

Perhaps this solves the problem you mention, or perhaps could provide a little 
inspiration?


Cheers,
=David

Re: Bndtools & Karaf : the right way

The point is that bndtools can generate resources descriptor, not 
features XML. That's why, in the way of generate "Karaf" applications 
directly in bndtools, it would be easier if Karaf feature can be 
described as resources, instead of XML.

@David, correct me if I'm wrong ;)

Regards
JB

On 11/30/2015 10:44 AM, Guillaume Nodet wrote:

It would be easier to start from the real requirements rather than from
a possible solution...

David, could you briefly outline what you want to achieve without going
into a possible solution ?

2015-11-30 10:40 GMT+01:00 Jean-Baptiste Onofré >:

David wants to create a "dummy bundle", describing a feature as
resources (without the XML).

Not yet sure it's a good idea (it's what we discussed on IRC).

Regards
JB

On 11/30/2015 10:36 AM, Guillaume Nodet wrote:

2015-11-30 8:41 GMT+01:00 David Leangen 
>>:

 >> There is an easy way to install bundles.
 >> Just use the feature:requirement-add command.

 Sounds practical. But then again, I really like the
idea of
 “features”. I like to see which “feature” is
installed and
 running. If my bundle is only added as a
requirement, then I
 lose that visibility. Also, having to restart Karaf
each time
 I want to add a new repository (as is currently the
case) is
 not a very nice option for me.

 Jean-Baptiste is working on that.
 I've also pushed support for referencing xml
repositories from
 features files to a github branch
https://github.com/gnodet/karaf/tree/KARAF-4130

 Looks nice!

 I noticed that currently, it is not possible to add a new
Feature
 via the FeatureService. Although there is an
addFeature(Feature)
 type method in the API, in practice it will not work if
there is not
 a corresponding XML repo.

 It would be very nice to be able to create a feature on the
fly,
 such as by wrapping a bundle, then add it via the service.
Actually,
 for what I am trying to do it would be “necessary”. :-)

I'm not sure i understand this requirement.  How can you
programmatically generate the feature definition ? What's your input
exactly ?

 Should I file a JIRA issue for this?

 In any case, feature:requirement-add is currently
not working
 for me, for 2 reasons…

 1) The patch I submitted to allow resolution of
resources with
 relative URLs only works when
  there is one single Repository added to the
config file.
 I am investigating an updated fix, but:

 2) Something odd happens intermittently when I try
to add a
 requirement. Karaf adds “type=karaf.feature”
  even when I express the type as “osgi.bundle”.
Example:

 karaf@root()> feature:requirement-add
 ‘osgi.identity=my.bundle;type=osgi.bundle'
 Error executing command: Unable to resolve root:
missing
 requirement [root] osgi.identity;

osgi.identity=“osgi.identity=my.bundle;type=osgi.bundle";
 type=karaf.feature;

filter:="(&(osgi.identity=osgi.identity=my.bundle;type=osgi.bundle)(type=karaf.feature))”

 Try with feature:requirement-add

‘requirement:osgi.identity;osgi.identity=my.bundle;type=osgi.bundle'

 Still trying. I must be doing something wrong… :-(

 Cheers,
 =David

--
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 - http://www.talend.com

Re: Bndtools & Karaf : the right way

Btw, reading your initial email, I want to mention I've been working on a
blueprint extension to support Spring-DM.  It's not complete yet, but it
may already cover your use case.
So the blueprint-spring bundle provides an Blueprint Aries NamespaceHandler
that support the spring core namespace.  With this bundle only, you need to
provide a blueprint entry point (i.e. a blueprint xml at the correct
location in your bundle) which can either embed spring bean definitions, or
even import spring xmls.
An additional module, blueprint-spring-extender, provides a Spring-DM like
extender, i.e. it will scan META-INF/spring/*.xml (or whatever is
configured in the Spring-Context header) and create an blueprint container
for it.
That's totally separate from the problem with bndtools, but worth
mentioning ;-)

https://github.com/apache/aries/tree/trunk/blueprint/blueprint-spring
https://github.com/apache/aries/tree/trunk/blueprint/blueprint-spring-extender

Cheers,
Guillaume

2015-11-25 15:41 GMT+01:00 deadbrain :

> Hi all  Karaf gurus,
> just a little question dealing with BndTools, I am supposed to refactor
> an existing Spring DM application into an OSGi + Blueprint application
> to be deployed inside ServiceMix (3.4 or 4). As a consequence I would
> like to use Bndtools but launching Karaf rather than the defaut Gogo
> shell would be more convenient.
>  What is the best way to do that ?
> I am supposed to write or reuse an ApplicationFactory ? I found a couple
> of implementations in github (ready to use ?)
> Is there any other  valuable option?
>
> Kind regards
> Jerome
>

Re: Bndtools & Karaf : the right way

So IIUC, you end up with "something" (what does it look like exactly ?)
that roughly is a list of requirements to bundles (so something like the
osgi.bundle=xxx;osgi.type=osgi.bundle requirement), and you want to install
that ?
So the idea would be to generate a feature on the fly with those
requirements ?

I suppose we could add them individually as input to the deployer, but
then, it would make management more complicated, especially when you want
to uninstall it.  That would be the main reason to keep a representation of
this list of requirements as a feature.

Am i understanding things correctly ?


2015-11-30 10:49 GMT+01:00 Jean-Baptiste Onofré :

> The point is that bndtools can generate resources descriptor, not features
> XML. That's why, in the way of generate "Karaf" applications directly in
> bndtools, it would be easier if Karaf feature can be described as
> resources, instead of XML.
>
> @David, correct me if I'm wrong ;)
>
> Regards
> JB
>
> On 11/30/2015 10:44 AM, Guillaume Nodet wrote:
>
>> It would be easier to start from the real requirements rather than from
>> a possible solution...
>>
>> David, could you briefly outline what you want to achieve without going
>> into a possible solution ?
>>
>> 2015-11-30 10:40 GMT+01:00 Jean-Baptiste Onofré > >:
>>
>> David wants to create a "dummy bundle", describing a feature as
>> resources (without the XML).
>>
>> Not yet sure it's a good idea (it's what we discussed on IRC).
>>
>> Regards
>> JB
>>
>> On 11/30/2015 10:36 AM, Guillaume Nodet wrote:
>>
>>
>>
>> 2015-11-30 8:41 GMT+01:00 David Leangen > 
>> >>:
>>
>>
>>
>>
>>  >> There is an easy way to install bundles.
>>  >> Just use the feature:requirement-add command.
>>
>>  Sounds practical. But then again, I really like the
>> idea of
>>  “features”. I like to see which “feature” is
>> installed and
>>  running. If my bundle is only added as a
>> requirement, then I
>>  lose that visibility. Also, having to restart Karaf
>> each time
>>  I want to add a new repository (as is currently the
>> case) is
>>  not a very nice option for me.
>>
>>
>>  Jean-Baptiste is working on that.
>>  I've also pushed support for referencing xml
>> repositories from
>>  features files to a github branch
>> https://github.com/gnodet/karaf/tree/KARAF-4130
>>
>>
>>  Looks nice!
>>
>>  I noticed that currently, it is not possible to add a new
>> Feature
>>  via the FeatureService. Although there is an
>> addFeature(Feature)
>>  type method in the API, in practice it will not work if
>> there is not
>>  a corresponding XML repo.
>>
>>  It would be very nice to be able to create a feature on the
>> fly,
>>  such as by wrapping a bundle, then add it via the service.
>> Actually,
>>  for what I am trying to do it would be “necessary”. :-)
>>
>>
>> I'm not sure i understand this requirement.  How can you
>> programmatically generate the feature definition ? What's your
>> input
>> exactly ?
>>
>>
>>  Should I file a JIRA issue for this?
>>
>>
>>
>>  In any case, feature:requirement-add is currently
>> not working
>>  for me, for 2 reasons…
>>
>>  1) The patch I submitted to allow resolution of
>> resources with
>>  relative URLs only works when
>>   there is one single Repository added to the
>> config file.
>>  I am investigating an updated fix, but:
>>
>>  2) Something odd happens intermittently when I try
>> to add a
>>  requirement. Karaf adds “type=karaf.feature”
>>   even when I express the type as “osgi.bundle”.
>> Example:
>>
>>  karaf@root()> feature:requirement-add
>>  ‘osgi.identity=my.bundle;type=osgi.bundle'
>>  Error executing command: Unable to resolve root:
>> missing
>>  requirement [root] osgi.identity;
>>
>> osgi.identity=“osgi.identity=my.bundle;type=osgi.bundle";
>>  type=karaf.feature;
>>
>>
>> filter:="(&(osgi.identity=osgi.identity=my.bundle;type=osgi.bundle)(type=karaf.feature))”
>>
>>
>>  Try with feature:requirement-add
>>
>>
>>

Re: Bndtools & Karaf : the right way

2015-11-30 Thread Christian Schneider

I think it might make more sense to allow a bundle to be a "feature"
definition too.

JB, Peter Kriens and me discussed about this on friday over skype. A
bundle with just a Manifest

can express most of the things a feature can express.

Require-Bundle can express requirements on certain bundles with version
ranges. It can also express optional dependencies.

Require-Capability can express other requirements.
Capability can express that the bundle implements a feature with a given
name and version it can also define any other capabilities.
The Configurer extender from enroute which might be standardized can
express default configs.

As Guillaume expressed on IRC there are definitely cases such a bundle
can not express (like conditionals or start levels or overwriting
files). It could be sufficient for a lot of

business cases though.

As far as I understood from David as well as from Peter such
(application) bundles are used in bndtools a bit like we use features in
karaf.

One advantage of such bundles is that they can be easily produced by
bndtools (together with an index to resolve against) and even eclipse pde.
They also use the default resolver mechanics. So they can be resolved
against a bndtools index as well as as a p2 repository. If we find
solutions to some of the problems Guillaume
mentioned then we might have a way for e.g. CXF to express their
features in a way that works on all OSGi platforms.

So what we could do on the karaf side is either have a special feature
command to install such a bundle or have an option of the bundle:install
command

to install a bundle + its dependencies resolved by the resolver.

As a short term solution we could even just work with just karaf as is
by creating a feature.xml that refers to the index and a feature that
refers to the application bundle. It is a little overhead but would
allow us to work out the idea some more without requiring bigger changes
in karaf.

This idea is still in an early stage but I think it has a lot of
potential and it should make sense to experiment with it.

Christian

On 30.11.2015 10:40, Jean-Baptiste Onofré wrote:
David wants to create a "dummy bundle", describing a feature as
resources (without the XML).

Not yet sure it's a good idea (it's what we discussed on IRC).

Regards
JB

On 11/30/2015 10:36 AM, Guillaume Nodet wrote:

2015-11-30 8:41 GMT+01:00 David Leangen >:

>> There is an easy way to install bundles.
>> Just use the feature:requirement-add command.

Sounds practical. But then again, I really like the idea of
“features”. I like to see which “feature” is installed and
running. If my bundle is only added as a requirement, then I
lose that visibility. Also, having to restart Karaf each time
I want to add a new repository (as is currently the case) is
not a very nice option for me.

Jean-Baptiste is working on that.
I've also pushed support for referencing xml repositories from
features files to a github branch
https://github.com/gnodet/karaf/tree/KARAF-4130

Looks nice!

I noticed that currently, it is not possible to add a new Feature
via the FeatureService. Although there is an addFeature(Feature)
type method in the API, in practice it will not work if there is not
a corresponding XML repo.

It would be very nice to be able to create a feature on the fly,
such as by wrapping a bundle, then add it via the service. Actually,
for what I am trying to do it would be “necessary”. :-)

I'm not sure i understand this requirement. How can you
programmatically generate the feature definition ? What's your input
exactly ?

Should I file a JIRA issue for this?

In any case, feature:requirement-add is currently not working
for me, for 2 reasons…

1) The patch I submitted to allow resolution of resources with
relative URLs only works when
there is one single Repository added to the config file.
I am investigating an updated fix, but:

2) Something odd happens intermittently when I try to add a
requirement. Karaf adds “type=karaf.feature”
even when I express the type as “osgi.bundle”. Example:

karaf@root()> feature:requirement-add
‘osgi.identity=my.bundle;type=osgi.bundle'
Error executing command: Unable to resolve root: missing
requirement [root] osgi.identity;
osgi.identity=“osgi.identity=my.bundle;type=osgi.bundle";
type=karaf.feature;
filter:="(&(osgi.identity=osgi.identity=my.bundle;type=osgi.bundle)(type=karaf.feature))”

Try with feature:requirement-add
‘requirement:osgi.identity;osgi.identity=my.bundle;type=osgi.bundle'

Still trying. I must be doing something wrong… :-(

Cheers,
=David

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

Open Source Architect

Re: Bndtools & Karaf : the right way

2015-11-30 11:03 GMT+01:00 Christian Schneider :

> I think it might make more sense to allow a bundle to be a "feature"
> definition too.
>

I don't think those bundles are really related (or need to be) to features.

>
> JB, Peter Kriens and me discussed about this on friday over skype. A
> bundle with just a Manifest
> can express most of the things a feature can express.

> Require-Bundle can express requirements on certain bundles with version
> ranges. It can also express optional dependencies.
> Require-Capability can express other requirements.
> Capability can express that the bundle implements a feature with a given
> name and version it can also define any other capabilities.
>

Yeah, when you remove all the things in features that can't ;-)

> The Configurer extender from enroute which might be standardized can
> express default configs.
>

I've had a very brief look at the RFC, it looks quite similar to what we've
done with features.

> As Guillaume expressed on IRC there are definitely cases such a bundle can
> not express (like conditionals or start levels or overwriting files). It
> could be sufficient for a lot of
> business cases though.
>

Right.  The problem is that leading users into a direction where they'll be
blocked once they get out of the simple cases is not a good idea to me.
Features are not very difficult to generate and write, we should be able to
find a way to integrate their generation into the bndtools chain.

>
> As far as I understood from David as well as from Peter such (application)
> bundles are used in bndtools a bit like we use features in karaf.
>

Yeah, and that's clearly the problem I have.  They start from a bunch of
common requirements we have, but just a subset.  So what we need is to have
bndtools sufficiently opened, so that we can add our own requirements and
generate what we need (i.e. a feature file).

>
> One advantage of such bundles is that they can be easily produced by
> bndtools (together with an index to resolve against) and even eclipse pde.
> They also use the default resolver mechanics. So they can be resolved
> against a bndtools index as well as as a p2 repository. If we find
> solutions to some of the problems Guillaume
> mentioned then we might have a way for e.g. CXF to express their features
> in a way that works on all OSGi platforms.
>

CXF is a good use case.  Unfortunately, this is not a simple one.  For
example, CXF has requirements on xalan / xerces, which aren't even
expressed in the feature yet.  Support for libraries has been added to
Karaf 4.x, but the feature has not been upgraded yet.  This is another
requirement which do not fit into the simple "application bundle" model.

>
> So what we could do on the karaf side is either have a special feature
> command to install such a bundle or have an option of the bundle:install
> command
> to install a bundle + its dependencies resolved by the resolver.
>

We already have the code supporting it.  And we can't use bundle:install
command for it.  It should be a feature:xxx command.  The bundle:install
commands are simple wrappers around the bundle context methods and I think
we should keep them this way.  The feature:xxx command do use the resolver
and we can easily add a new command to the list.
Right now, with the modifications I wrote to support OSGi Resource
Repositories inside features repositories, it should be quite simple to
implement:

xml:url-to-the-repository-xml

requirement:osgi.identity;osgi.identity=application-bundle;osgi.type=xxx;version=xxx

We could easily write a simple command to generate such a feature by simply
giving the repository xml and the identity of the application bundle, but
JB has been working on commands to add resource repositories, so it would
already translate into 2 simple command calls:
   feature:resource-repository-add xml:url-to-the-repository-xml
   feature:requirement-add
'requirement:osgi.identity;osgi.identity=application-bundle;osgi.type=xxx;version=xxx'

> As a short term solution we could even just work with just karaf as is by
> creating a feature.xml that refers to the index and a feature that refers
> to the application bundle. It is a little overhead but would
> allow us to work out the idea some more without requiring bigger changes
> in karaf.
>
> This idea is still in an early stage but I think it has a lot of potential
> and it should make sense to experiment with it.
>
> Christian
>
>
> On 30.11.2015 10:40, Jean-Baptiste Onofré wrote:
>
>> David wants to create a "dummy bundle", describing a feature as resources
>> (without the XML).
>>
>> Not yet sure it's a good idea (it's what we discussed on IRC).
>>
>> Regards
>> JB
>>
>> On 11/30/2015 10:36 AM, Guillaume Nodet wrote:
>>
>>>
>>>
>>> 2015-11-30 8:41 GMT+01:00 David Leangen >> >:
>>>
>>>
>>> >> There is an easy way to install bundles.
 >> Just use the

Re: Bndtools & Karaf : the right way

Yes, it's what I understood too.

Regards
JB

On 11/30/2015 10:58 AM, Guillaume Nodet wrote:

So IIUC, you end up with "something" (what does it look like exactly ?)
that roughly is a list of requirements to bundles (so something like the
osgi.bundle=xxx;osgi.type=osgi.bundle requirement), and you want to
install that ?
So the idea would be to generate a feature on the fly with those
requirements ?

I suppose we could add them individually as input to the deployer, but
then, it would make management more complicated, especially when you
want to uninstall it.  That would be the main reason to keep a
representation of this list of requirements as a feature.

Am i understanding things correctly ?

2015-11-30 10:49 GMT+01:00 Jean-Baptiste Onofré >:

The point is that bndtools can generate resources descriptor, not
features XML. That's why, in the way of generate "Karaf"
applications directly in bndtools, it would be easier if Karaf
feature can be described as resources, instead of XML.

@David, correct me if I'm wrong ;)

Regards
JB

On 11/30/2015 10:44 AM, Guillaume Nodet wrote:

It would be easier to start from the real requirements rather
than from
a possible solution...

David, could you briefly outline what you want to achieve
without going
into a possible solution ?

2015-11-30 10:40 GMT+01:00 Jean-Baptiste Onofré 
>>:

 David wants to create a "dummy bundle", describing a feature as
 resources (without the XML).

 Not yet sure it's a good idea (it's what we discussed on IRC).

 Regards
 JB

 On 11/30/2015 10:36 AM, Guillaume Nodet wrote:

 2015-11-30 8:41 GMT+01:00 David Leangen

 >

> There is an easy way to install bundles.
  >> Just use the feature:requirement-add
command.

  Sounds practical. But then again, I really
like the
 idea of
  “features”. I like to see which “feature” is
 installed and
  running. If my bundle is only added as a
 requirement, then I
  lose that visibility. Also, having to
restart Karaf
 each time
  I want to add a new repository (as is
currently the
 case) is
  not a very nice option for me.

  Jean-Baptiste is working on that.
  I've also pushed support for referencing xml
 repositories from
  features files to a github branch
https://github.com/gnodet/karaf/tree/KARAF-4130

  Looks nice!

  I noticed that currently, it is not possible to
add a new
 Feature
  via the FeatureService. Although there is an
 addFeature(Feature)
  type method in the API, in practice it will not
work if
 there is not
  a corresponding XML repo.

  It would be very nice to be able to create a
feature on the
 fly,
  such as by wrapping a bundle, then add it via the
service.
 Actually,
  for what I am trying to do it would be
“necessary”. :-)

 I'm not sure i understand this requirement.  How can you
 programmatically generate the feature definition ?
What's your input
 exactly ?

  Should I file a JIRA issue for this?

  In any case, feature:requirement-add is
currently
 not working
  for me, for 2 reasons…

  1) The patch I submitted to allow
resolution of
 resources with
  relative URLs only works when
   there is one single Repository added
to the
 config file.
  I am investigating an updated fix, but:

  2) Something odd happens intermittently
when I try
 to add a

Re: Bndtools & Karaf : the right way

2015-11-30 Thread Christian Schneider

Honestly while working with karaf we always had a maven centric world so 
we are bit biased I guess.

For me the core of maven is the maven repository.

Before maven there were thousands of places to get jars from. As there 
was no reliable place to get dependencies from most projects put their 
dependencies into a zip/or tar.gz file that formed the distro.


1. Maven keeps your source repository free from binaries
So the first good thing in maven is that each jar has a (kind of) world 
wide unique id. So instead of putting a dependency into your source 
control system you only refer to it using this id.


2. Maven central the place where you can get almost any jar available as 
open source


3. Companies can transparently mirror external repositories like maven 
central. So your project still has the same maven id for the artifact 
but you can route all through your company repository. There you can

do the mirroring, caching, security checks, license checks

4. In the karaf case the maven repository is a nice place to load 
artifacts from. Again the maven id is the same and you can route through 
your company repository.


5. Every code your teams produce goes to the company maven repository. 
So the repository is the way your teams can hand over snapshots and 
releases.


6. Maven has a nice snapshot handling. So open source projects as well 
as company teams can have their CI build push to a maven snapshot repo 
for any other to retrieve the newest versions from. This significantly 
shortens development cycles as you have the chance to find bugs before 
the release is done. We use this extensively for the projects karaf 
integrates.


So as you see it is not the build system. I would be interested how you 
do all the things above without the maven repo.


Christian



On 30.11.2015 13:17, David Leangen wrote:

Hi,


I think the maven repository is also a really nice hand over point between the 
developer and deployer roles you defined. The developer builds the bundles as 
well as the
index into the maven repository and the deployer installs from there.


Perhaps you could explain to me why, other than for backwards compatibility and 
perhaps because of wide adoption, working with maven is such a good thing? For 
those reasons, I agree that maven is necessary to maintain; but to chain people 
to maven, I am not so sure.

It seems to me that the OSGi model (OBR) is enough, and is the “OSGi Way”. 
Maven is a different world. Since I have been maven-free, it has been quite 
liberating. I see OSGi in a different (IMO nicer) way now. :-)

Just my 2yen.

Cheers,
=David





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

Open Source Architect
http://www.talend.com

Re: Bndtools & Karaf : the right way


One or another "alone" is not good.

Supporting both makes sense.

Regards
JB

On 11/30/2015 01:17 PM, David Leangen wrote:


Hi,


I think the maven repository is also a really nice hand over point between the 
developer and deployer roles you defined. The developer builds the bundles as 
well as the
index into the maven repository and the deployer installs from there.



Perhaps you could explain to me why, other than for backwards compatibility and 
perhaps because of wide adoption, working with maven is such a good thing? For 
those reasons, I agree that maven is necessary to maintain; but to chain people 
to maven, I am not so sure.

It seems to me that the OSGi model (OBR) is enough, and is the “OSGi Way”. 
Maven is a different world. Since I have been maven-free, it has been quite 
liberating. I see OSGi in a different (IMO nicer) way now. :-)

Just my 2yen.

Cheers,
=David




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

Re: Bndtools & Karaf : the right way

2015-11-30 Thread development

 

>From my standpoint I think the way features are in xml is really
convenient. That being said I am not sure what there is in features.xml
that could not be built off of stuff already in the osgi standard or
being proposed. Personally I feel the start level should be set by the
resolver and done by adding requirements. If you depend on another
feature being installed then there should be a requirement for it and
setting a later start level seems more of a hack for getting around
bundles that have requirements but don't list them and instead make
assumptions. To me a conditional boils down to being a calculated
requirement. I am not sure but it would be nice if you could use the
same approach that was used for osgi.type = karaf.feature. If you had an
osgi.type = karaf.conditional.{conditional_config_pid}, if karaf sees a
requirement that starts with karaf.conditional it will use the
configuration data at the pid to determine if the bundle should be
installed or not. As pointed out earlier the configurator could be used
to do the file deployment. I could see how there would be issues with
system provided packages and examples like you gave for cxf but I think
that the base system should be providing those as capabilities somehow.
That or the projects could check if they have all their dependent
libraries and if not deploy the jar and include it in the classpath.
Anyway, I like the features the way they are but it would be nice if you
could find a way to get the same functionality by using the standard
similar to how you did for getting features to use the standard
resolver. This would give the capability to use stuff like cxf outside
of karaf without needing an in depth knowledge of all its dependencies. 

David Daniel 

On 2015-11-30 05:21, Guillaume Nodet wrote: 

> 2015-11-30 11:03 GMT+01:00 Christian Schneider :
> 
>> I think it might make more sense to allow a bundle to be a "feature" 
>> definition too.
> 
> I don't think those bundles are really related (or need to be) to features. 
> 
>> JB, Peter Kriens and me discussed about this on friday over skype. A bundle 
>> with just a Manifest
>> can express most of the things a feature can express.
> 
>> Require-Bundle can express requirements on certain bundles with version 
>> ranges. It can also express optional dependencies.
>> Require-Capability can express other requirements.
>> Capability can express that the bundle implements a feature with a given 
>> name and version it can also define any other capabilities.
> 
> Yeah, when you remove all the things in features that can't ;-) 
> 
>> The Configurer extender from enroute which might be standardized can express 
>> default configs.
> 
> I've had a very brief look at the RFC, it looks quite similar to what we've 
> done with features. 
> 
>> As Guillaume expressed on IRC there are definitely cases such a bundle can 
>> not express (like conditionals or start levels or overwriting files). It 
>> could be sufficient for a lot of
>> business cases though.
> 
> Right. The problem is that leading users into a direction where they'll be 
> blocked once they get out of the simple cases is not a good idea to me. 
> Features are not very difficult to generate and write, we should be able to 
> find a way to integrate their generation into the bndtools chain. 
> 
>> As far as I understood from David as well as from Peter such (application) 
>> bundles are used in bndtools a bit like we use features in karaf.
> 
> Yeah, and that's clearly the problem I have. They start from a bunch of 
> common requirements we have, but just a subset. So what we need is to have 
> bndtools sufficiently opened, so that we can add our own requirements and 
> generate what we need (i.e. a feature file). 
> 
>> One advantage of such bundles is that they can be easily produced by 
>> bndtools (together with an index to resolve against) and even eclipse pde.
>> They also use the default resolver mechanics. So they can be resolved 
>> against a bndtools index as well as as a p2 repository. If we find solutions 
>> to some of the problems Guillaume
>> mentioned then we might have a way for e.g. CXF to express their features in 
>> a way that works on all OSGi platforms.
> 
> CXF is a good use case. Unfortunately, this is not a simple one. For example, 
> CXF has requirements on xalan / xerces, which aren't even expressed in the 
> feature yet. Support for libraries has been added to Karaf 4.x, but the 
> feature has not been upgraded yet. This is another requirement which do not 
> fit into the simple "application bundle" model. 
> 
>> So what we could do on the karaf side is either have a special feature 
>> command to install such a bundle or have an option of the bundle:install 
>> command
>> to install a bundle + its dependencies resolved by the resolver.
> 
> We already have the code supporting it. And we can't use bundle:install 
> command for it. It should be a feature:xxx command. The bundle:install

Re: Bndtools & Karaf : the right way

2015-11-30 Thread Christian Schneider




Am 01.12.2015 um 05:55 schrieb David Leangen:



So as you see it is not the build system. I would be interested how you do all 
the things above without the maven repo.

I get the feeling that you are comparing apples to smoothies. The apple is the 
actual repository, i.e. convention as to where and how the data is stored, 
while the smoothie is what you do with it. I think that OBR is a more advanced 
apple than maven, but nobody has really developed the smoothie yet, so maven 
has the better smoothie. You seem more interested in the smoothie, maybe. (Ok, 
bad metaphor??)

Since maven is so widely adopted, it would be foolish to ignore. That is not 
what I am suggesting. However, I think it would not be wise to force Karaf 
users into the maven world, either.
You are right. For OSGi we need a repository with support for OSGi 
metadata. Only then can we use the resolver in an efficient way.
I think an OBR like Cave is the wrong approach though. It want to index 
the whole repository which does not work on the scale of maven repos 
especially not for maven central.


I think the nice middle ground is using the maven indexer plugin the Tim 
Ward created. I plan to use this plugin in the build process of the 
apache projects (per project and per version). So for example hibernate 
5.0.0 would create an index with all the bundles it needs. This index is 
then stored in the maven repository as a file.


So this has two advantages.
1. The index does not have any conflicting bundles
2. The index is small and easy to handle.

So I think this has the potential to combine the advantages of maven and 
obr.


I really like the way that Karaf has handled blueprint vs. DS. Kara itself is 
based in part on blueprint, but I am not forced to use it. This, I do not mind 
at all. Even when I list the current bundles, by default I don’t even have to 
look at the stuff installed behind the scenes. I was initially worried about 
all the “stuff” getting installed, but I have relaxed a bit.

For Karaf commands, also at first I was not happy that it forced me to decided 
“either or” simple gogo commands or Karaf commands. However, the commands 
really are nice. I think somebody should push to have completes and all the 
other nice stuff added to the OSGi spec.
Fully agree. I was never a fan of the karaf command style. The felix 
ones are much nicer in regard to OSGi services and we should bring them 
en part with the karaf style and support both styles in karaf. It would 
also be great to then put the enhancement into a spec.
I would really like to see commands that are then usable in karaf but 
also in plain OSGi frameworks or even outside OSGi. There is no reason 
why all of these must be different.


Christian

Re: Bndtools & Karaf : the right way

My understanding is that, as I explained in my earlier mail,
you don't need features at all.
If you have an "application bundle" and the xml repository, that should be
enough, you don't have to wrap them.

Could you please raise a JIRA and attach the artefacts needed to
"reproduce" the use case ? I.e. maybe a zip containing the xml repository
and the bundles, including the application bundle.
I'll investigate to make sure you can deploy it easily.

2015-11-30 11:39 GMT+01:00 David Leangen :

>
> Hi,
>
> Wow! This list is really active. :-D
>
> I think Christian explains it quite well. Allow me to add in more
> concrete, low-level details to complement this explanation.
>
> First of all, I have a “bootstrapping" bundle, with no dependencies on any
> of my other bundles, but some dependencies on, for example, Karaf. This
> bundle handles the deployment functions described below. This bundle is set
> up as a boot feature in Karaf. Along with the things being discussed below,
> it will allow me to accomplish my objective.
>
>
> In my development environment, I have several bndtools workspaces in
> Eclipse. I believe this is quite typical in a bndtools environment. Each
> workspace usually (but not always) has an “application bundle”, whose
> purpose is to pull in all the requirements for the “application” (what is,
> I believe, essentially homologous to a Karaf feature, minus the
> configuration).
>
> In my enRoute application bundles, I created a KarafFeature annotation
> like this:
>
> @ProvideCapability(
> ns = "karaf.identity",
> value = "type=karaf.feature"
> )
> @Retention(RetentionPolicy.CLASS)
> public @interface KarafFeature
> {
> String name();
> String description();
> String version();
> }
>
> Used on my “application service” class:
>
> @RequireTestFoo
> @RequireTestBar
> @KarafFeature(
> name = “feature-name",
> description = “Short description of feature",
> version = “1.0.0"
> )
> public class TestInstallation
> {
> }
>
> The capability output via bnd to the Manifest:
>
>   Provide-Capability: karaf.identity;description=“Short description of
> feature";version:Version=“1.0.0";karaf.identity=feature-name;type="karaf.feature"
>
> [**Note:
>
> The requirement for a feature is already formalized in karaf:
>
> osgi.identity;osgi.identity=feature-name;type=karaf.feature;version="version-range"
>
>
> I tried this, but apparently bnd does not like it, so in my implementation
> I changed it from “osgi.identity” to “karaf.identity”. I don’t know if this
> is a bug in bnd, or if Karaf is using osgi.identity for something it should
> not. :-)  ]
>
> bnd provides a “release” function, which creates an OBR with all the
> bundles from the workspace. This can be done via Eclipse or as a headless
> build from gradle. Thus, for each workspace, on the CI server, when a build
> is successful, the result is an OBR repo as the output.
>
> I currently use Bamboo for our CI server. It has a “deployment” function,
> which we use to push the released OBR repos to a repository server. The
> developer’s job ends here, as this is also the handoff point to the
> deployer. I believe that the roles should be separated. From a business
> perspective, if we required that a deployer has the same level of expertise
> as a developer, things would be very expensive. ;-)
>
> In crappy ASCII art, it would be:
>
> +-+ ++
> | Dev |——>[OBR Repos]<——| Deploy |
> +-+ ++
>
> Once in Karaf, since I want to have a local cache of my OBR repositories
> in order to completely decouple the runtime system from any development or
> deployment system, I (programmatically) have Cave populate corresponding
> local caches. So my deployment bundle will first obtain and cache the OBR
> repositories (one for each bnd workspace) and cache it locally via Cave.
>
> The deployer, when initiating a deployment, will therefore pull the
> released OBR repos via Cave. I then parse the respository.xml file to find
> any capabilities in the karaf.identity namespace, and pull in any
> information I need to create a Karaf feature on the fly. (Probably you can
> imagine this, but I can show you the fairly trivial code if necessary.)
>
> I have an XML parser that will extract the information necessary to
> generate the Karaf feature from the capabilities in the application bundle
> in each Repo. However, if I could input either the bundle or the repo and
> let Karaf extract the feature information, that would be even better.
>
> Based on the above, I could easily create Karaf commands to allow the
> deployer to pull in the latest versions (deployed as OBR repos) and deploy
> as necessary as features, which would be generated on the fly from the
> included capabilities.
>
> I believe that this would be a very nice, easy, and natural way to
> “integrate” an eRoute (bnd) development environment with the Karaf runtime.
> Developers continue to

Re: Bndtools & Karaf : the right way


> I think something that might work is:
> 
> feature:install [;]

That sounds very nice.

> We could support this syntax alternatively to a simple feature name.
> 
> Do you think we need a special way to track the installed application/feature 
> bundles? Or is it good enough that they are present in the system as bundles? 
> If I understood correctly then the feature
> service would uninstall bundles that are not part of an installed feature if 
> they are marked as managed.

Yes, absolutely. The goal would be to install and uninstall the 
workspace/application bundles as a unit (assuming that no other “applications” 
are using a dependency).

The features show a nice list of what is installed. This is exactly the type of 
list that would be very useful to show which workspaces/applications are 
installed.

> In any case I think with the combination of repository indexes and 
> application/feature bundles we are on a very promising path.

Sounds so to me. :-)

> I hope the next version of bndtools will make it easier to create the 
> artifacts in a more maven centric way. So both the bundles and indexes 
> created by bndtools are made available in the maven repository. This would 
> then
> be a very natural integration into the karaf deployment process. We could 
> then allow custom distributions to specify a mvn url to an index like we do 
> for a feature. The plugin could then copy the index as well as all bundles
> referenced in the index into the karaf system dir so the result is standalone.

When I moved to bndtools, I also moved over to the gradle world. I just hope 
that this won’t force me back to maven. :-)


Cheers,
=David

Re: Bndtools & Karaf : the right way


feature:install with SymbolicName sounds good.

I think tracking feature is a must have to be aligned with the current 
expectations.


I agree that if bndtools is able to better deal with Maven, it would 
help a lot.


Regards
JB

On 11/30/2015 12:07 PM, Christian Schneider wrote:

I think something that might work is:

feature:install [;]

We could support this syntax alternatively to a simple feature name.

Do you think we need a special way to track the installed
application/feature bundles? Or is it good enough that they are present
in the system as bundles? If I understood correctly then the feature
service would uninstall bundles that are not part of an installed
feature if they are marked as managed.

In any case I think with the combination of repository indexes and
application/feature bundles we are on a very promising path.

I hope the next version of bndtools will make it easier to create the
artifacts in a more maven centric way. So both the bundles and indexes
created by bndtools are made available in the maven repository. This
would then
be a very natural integration into the karaf deployment process. We
could then allow custom distributions to specify a mvn url to an index
like we do for a feature. The plugin could then copy the index as well
as all bundles
referenced in the index into the karaf system dir so the result is
standalone.

Christian

On 30.11.2015 11:51, Guillaume Nodet wrote:

My understanding is that, as I explained in my earlier mail,
you don't need features at all.
If you have an "application bundle" and the xml repository, that
should be enough, you don't have to wrap them.

Could you please raise a JIRA and attach the artefacts needed to
"reproduce" the use case ? I.e. maybe a zip containing the xml
repository and the bundles, including the application bundle.
I'll investigate to make sure you can deploy it easily.





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

Re: Bndtools & Karaf : the right way


Hi,

Wow! This list is really active. :-D

I think Christian explains it quite well. Allow me to add in more concrete, 
low-level details to complement this explanation.

First of all, I have a “bootstrapping" bundle, with no dependencies on any of 
my other bundles, but some dependencies on, for example, Karaf. This bundle 
handles the deployment functions described below. This bundle is set up as a 
boot feature in Karaf. Along with the things being discussed below, it will 
allow me to accomplish my objective.


In my development environment, I have several bndtools workspaces in Eclipse. I 
believe this is quite typical in a bndtools environment. Each workspace usually 
(but not always) has an “application bundle”, whose purpose is to pull in all 
the requirements for the “application” (what is, I believe, essentially 
homologous to a Karaf feature, minus the configuration).

In my enRoute application bundles, I created a KarafFeature annotation like 
this:

@ProvideCapability(
ns = "karaf.identity",
value = "type=karaf.feature"
)
@Retention(RetentionPolicy.CLASS)
public @interface KarafFeature
{
String name();
String description();
String version();
}

Used on my “application service” class:

@RequireTestFoo
@RequireTestBar
@KarafFeature(
name = “feature-name",
description = “Short description of feature",
version = “1.0.0"
)
public class TestInstallation
{
}

The capability output via bnd to the Manifest:

  Provide-Capability: karaf.identity;description=“Short description of 
feature";version:Version=“1.0.0";karaf.identity=feature-name;type="karaf.feature"

[**Note:

> The requirement for a feature is already formalized in karaf:
>
> osgi.identity;osgi.identity=feature-name;type=karaf.feature;version="version-range"


I tried this, but apparently bnd does not like it, so in my implementation I 
changed it from “osgi.identity” to “karaf.identity”. I don’t know if this is a 
bug in bnd, or if Karaf is using osgi.identity for something it should not. :-) 
 ]

bnd provides a “release” function, which creates an OBR with all the bundles 
from the workspace. This can be done via Eclipse or as a headless build from 
gradle. Thus, for each workspace, on the CI server, when a build is successful, 
the result is an OBR repo as the output.

I currently use Bamboo for our CI server. It has a “deployment” function, which 
we use to push the released OBR repos to a repository server. The developer’s 
job ends here, as this is also the handoff point to the deployer. I believe 
that the roles should be separated. From a business perspective, if we required 
that a deployer has the same level of expertise as a developer, things would be 
very expensive. ;-)

In crappy ASCII art, it would be:

+-+ ++ 
| Dev |——>[OBR Repos]<——| Deploy |
+-+ ++ 

Once in Karaf, since I want to have a local cache of my OBR repositories in 
order to completely decouple the runtime system from any development or 
deployment system, I (programmatically) have Cave populate corresponding local 
caches. So my deployment bundle will first obtain and cache the OBR 
repositories (one for each bnd workspace) and cache it locally via Cave.

The deployer, when initiating a deployment, will therefore pull the released 
OBR repos via Cave. I then parse the respository.xml file to find any 
capabilities in the karaf.identity namespace, and pull in any information I 
need to create a Karaf feature on the fly. (Probably you can imagine this, but 
I can show you the fairly trivial code if necessary.)

I have an XML parser that will extract the information necessary to generate 
the Karaf feature from the capabilities in the application bundle in each Repo. 
However, if I could input either the bundle or the repo and let Karaf extract 
the feature information, that would be even better.

Based on the above, I could easily create Karaf commands to allow the deployer 
to pull in the latest versions (deployed as OBR repos) and deploy as necessary 
as features, which would be generated on the fly from the included capabilities.

I believe that this would be a very nice, easy, and natural way to “integrate” 
an eRoute (bnd) development environment with the Karaf runtime. Developers 
continue to work as usual, in theory without having to worry about which 
runtime is being used, while the deployer can do her job very easily from start 
to finish from the Karaf command line without having to stop the system, change 
configuration, or even call on developers (unless something blows up).


Please let me know if I can provide any further info. :-)

Cheers,
=David

Re: Bndtools & Karaf : the right way


Hi,

> I think the maven repository is also a really nice hand over point between 
> the developer and deployer roles you defined. The developer builds the 
> bundles as well as the
> index into the maven repository and the deployer installs from there.


Perhaps you could explain to me why, other than for backwards compatibility and 
perhaps because of wide adoption, working with maven is such a good thing? For 
those reasons, I agree that maven is necessary to maintain; but to chain people 
to maven, I am not so sure.

It seems to me that the OSGi model (OBR) is enough, and is the “OSGi Way”. 
Maven is a different world. Since I have been maven-free, it has been quite 
liberating. I see OSGi in a different (IMO nicer) way now. :-)

Just my 2yen.

Cheers,
=David

Re: Bndtools & Karaf : the right way

I agree: if the "application" is exhaustive in term of requirements, and 
you define the resourcesRepositories, it should work.


Regards
JB

On 11/30/2015 11:51 AM, Guillaume Nodet wrote:

My understanding is that, as I explained in my earlier mail,
you don't need features at all.
If you have an "application bundle" and the xml repository, that should
be enough, you don't have to wrap them.

Could you please raise a JIRA and attach the artefacts needed to
"reproduce" the use case ? I.e. maybe a zip containing the xml
repository and the bundles, including the application bundle.
I'll investigate to make sure you can deploy it easily.

2015-11-30 11:39 GMT+01:00 David Leangen >:


Hi,

Wow! This list is really active. :-D

I think Christian explains it quite well. Allow me to add in more
concrete, low-level details to complement this explanation.

First of all, I have a “bootstrapping" bundle, with no dependencies
on any of my other bundles, but some dependencies on, for example,
Karaf. This bundle handles the deployment functions described below.
This bundle is set up as a boot feature in Karaf. Along with the
things being discussed below, it will allow me to accomplish my
objective.


In my development environment, I have several bndtools workspaces in
Eclipse. I believe this is quite typical in a bndtools environment.
Each workspace usually (but not always) has an “application bundle”,
whose purpose is to pull in all the requirements for the
“application” (what is, I believe, essentially homologous to a Karaf
feature, minus the configuration).

In my enRoute application bundles, I created a KarafFeature
annotation like this:

@ProvideCapability(
 ns = "karaf.identity",
 value = "type=karaf.feature"
)
@Retention(RetentionPolicy.CLASS)
public@interfaceKarafFeature
{
 String name();
 String description();
 String version();
}

Used on my “application service” class:

@RequireTestFoo
@RequireTestBar
@KarafFeature(
 name = “feature-name",
 description = “Short description of feature",
 version = “1.0.0"
)
public class TestInstallation
{
}

The capability output via bnd to the Manifest:

   Provide-Capability: karaf.identity;description=“Short description
of

feature";version:Version=“1.0.0";karaf.identity=feature-name;type="karaf.feature"

[**Note:


The requirement for a feature is already formalized in karaf:

osgi.identity;osgi.identity=feature-name;type=karaf.feature;version="version-range"


I tried this, but apparently bnd does not like it, so in my
implementation I changed it from “osgi.identity” to
“karaf.identity”. I don’t know if this is a bug in bnd, or if Karaf
is using osgi.identity for something it should not. :-)  ]

bnd provides a “release” function, which creates an OBR with all the
bundles from the workspace. This can be done via Eclipse or as a
headless build from gradle. Thus, for each workspace, on the CI
server, when a build is successful, the result is an OBR repo as the
output.

I currently use Bamboo for our CI server. It has a “deployment”
function, which we use to push the released OBR repos to a
repository server. The developer’s job ends here, as this is also
the handoff point to the deployer. I believe that the roles should
be separated. From a business perspective, if we required that a
deployer has the same level of expertise as a developer, things
would be very expensive. ;-)

In crappy ASCII art, it would be:

+-+ ++
| Dev |——>[OBR Repos]<——| Deploy |
+-+ ++

Once in Karaf, since I want to have a local cache of my OBR
repositories in order to completely decouple the runtime system from
any development or deployment system, I (programmatically) have Cave
populate corresponding local caches. So my deployment bundle will
first obtain and cache the OBR repositories (one for each bnd
workspace) and cache it locally via Cave.

The deployer, when initiating a deployment, will therefore pull the
released OBR repos via Cave. I then parse the respository.xml file
to find any capabilities in the karaf.identity namespace, and pull
in any information I need to create a Karaf feature on the fly.
(Probably you can imagine this, but I can show you the fairly
trivial code if necessary.)

I have an XML parser that will extract the information necessary to
generate the Karaf feature from the capabilities in the application
bundle in each Repo. However, if I could input either the bundle or
the repo and let Karaf extract the feature information, that would
be even better.

Based on the above, I could easily create Karaf commands to allow

Re: Bndtools & Karaf : the right way

> My understanding is that, as I explained in my earlier mail,
> you don't need features at all.
> If you have an "application bundle" and the xml repository, that should be 
> enough, you don't have to wrap them.

Indeed, if it is possible to manage the bundles as a unit, like a feature does, 
then it would be just fine.

> Could you please raise a JIRA and attach the artefacts needed to "reproduce" 
> the use case ? I.e. maybe a zip containing the xml repository and the 
> bundles, including the application bundle.
> I'll investigate to make sure you can deploy it easily.

Ok, sure. It is already evening here, so I’ll have to get back to this a little 
later :-)

Cheers,
=David

Re: Bndtools & Karaf : the right way


Gradle can work with Maven.

On 11/30/2015 12:22 PM, David Leangen wrote:



I think something that might work is:

feature:install [;]


That sounds very nice.


We could support this syntax alternatively to a simple feature name.

Do you think we need a special way to track the installed application/feature 
bundles? Or is it good enough that they are present in the system as bundles? 
If I understood correctly then the feature
service would uninstall bundles that are not part of an installed feature if 
they are marked as managed.


Yes, absolutely. The goal would be to install and uninstall the 
workspace/application bundles as a unit (assuming that no other “applications” 
are using a dependency).

The features show a nice list of what is installed. This is exactly the type of 
list that would be very useful to show which workspaces/applications are 
installed.


In any case I think with the combination of repository indexes and 
application/feature bundles we are on a very promising path.


Sounds so to me. :-)


I hope the next version of bndtools will make it easier to create the artifacts 
in a more maven centric way. So both the bundles and indexes created by 
bndtools are made available in the maven repository. This would then
be a very natural integration into the karaf deployment process. We could then 
allow custom distributions to specify a mvn url to an index like we do for a 
feature. The plugin could then copy the index as well as all bundles
referenced in the index into the karaf system dir so the result is standalone.


When I moved to bndtools, I also moved over to the gradle world. I just hope 
that this won’t force me back to maven. :-)


Cheers,
=David



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

Re: Bndtools & Karaf : the right way

2015-11-30 12:07 GMT+01:00 Christian Schneider :

> I think something that might work is:
>
> feature:install [;]
>
> We could support this syntax alternatively to a simple feature name.
>
> Do you think we need a special way to track the installed
> application/feature bundles? Or is it good enough that they are present in
> the system as bundles? If I understood correctly then the feature
> service would uninstall bundles that are not part of an installed feature
> if they are marked as managed.
>

We don't have to track anything, it's already done.
If we translate the [;] into
requirement:osgi.identity;osgi.identity=;osgi.type=;version=
where  is the type defined by the "application bundle"
(it may be osgi.bundle, i haven't checked), then everything will work as
expected.
So the command would behave exactly as the requirement-add command, with
the translation in between, that's all.

However, I don't think it's generally a good idea to add global Resource
repositories to the resolver, as it impacts all other features.
If bndtool would use a different osgi.type to identity those application
bundles, we could have an even simpler command which would take a single
argument that would be the repository xml generated by obr.  The command
would load that repo, find the application bundles, wrap them into a
feature repository, and ask the FeaturesService to install them.
If we can't easily identify those application bundles, we'd need a second
argument to specify which bundles are "application bundles" to install.

Anyway, once I'm given a repository and a set of bundles to look at, i'm
willing to look at it.

>
> In any case I think with the combination of repository indexes and
> application/feature bundles we are on a very promising path.
>
> I hope the next version of bndtools will make it easier to create the
> artifacts in a more maven centric way. So both the bundles and indexes
> created by bndtools are made available in the maven repository. This would
> then
> be a very natural integration into the karaf deployment process. We could
> then allow custom distributions to specify a mvn url to an index like we do
> for a feature. The plugin could then copy the index as well as all bundles
> referenced in the index into the karaf system dir so the result is
> standalone.
>
> Christian
>
> On 30.11.2015 11:51, Guillaume Nodet wrote:
>
>> My understanding is that, as I explained in my earlier mail,
>> you don't need features at all.
>> If you have an "application bundle" and the xml repository, that should
>> be enough, you don't have to wrap them.
>>
>> Could you please raise a JIRA and attach the artefacts needed to
>> "reproduce" the use case ? I.e. maybe a zip containing the xml repository
>> and the bundles, including the application bundle.
>> I'll investigate to make sure you can deploy it easily.
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Re: Bndtools & Karaf : the right way

2015-11-30 8:41 GMT+01:00 David Leangen :

>
> >> There is an easy way to install bundles.
>> >> Just use the feature:requirement-add command.
>>
>> Sounds practical. But then again, I really like the idea of “features”. I
>> like to see which “feature” is installed and running. If my bundle is only
>> added as a requirement, then I lose that visibility. Also, having to
>> restart Karaf each time I want to add a new repository (as is currently the
>> case) is not a very nice option for me.
>>
>
> Jean-Baptiste is working on that.
> I've also pushed support for referencing xml repositories from features
> files to a github branch
>https://github.com/gnodet/karaf/tree/KARAF-4130
>
>
> Looks nice!
>
> I noticed that currently, it is not possible to add a new Feature via the
> FeatureService. Although there is an addFeature(Feature) type method in the
> API, in practice it will not work if there is not a corresponding XML repo.
>
> It would be very nice to be able to create a feature on the fly, such as
> by wrapping a bundle, then add it via the service. Actually, for what I am
> trying to do it would be “necessary”. :-)
>

I'm not sure i understand this requirement.  How can you programmatically
generate the feature definition ? What's your input exactly ?


>
> Should I file a JIRA issue for this?
>
>
>
> In any case, feature:requirement-add is currently not working for me, for
>> 2 reasons…
>>
>> 1) The patch I submitted to allow resolution of resources with relative
>> URLs only works when
>>  there is one single Repository added to the config file. I am
>> investigating an updated fix, but:
>>
>> 2) Something odd happens intermittently when I try to add a requirement.
>> Karaf adds “type=karaf.feature”
>>  even when I express the type as “osgi.bundle”. Example:
>>
>> karaf@root()> feature:requirement-add
>> ‘osgi.identity=my.bundle;type=osgi.bundle'
>> Error executing command: Unable to resolve root: missing requirement
>> [root] osgi.identity;
>> osgi.identity=“osgi.identity=my.bundle;type=osgi.bundle";
>> type=karaf.feature;
>> filter:="(&(osgi.identity=osgi.identity=my.bundle;type=osgi.bundle)(type=karaf.feature))”
>>
>>
> Try with feature:requirement-add
> ‘requirement:osgi.identity;osgi.identity=my.bundle;type=osgi.bundle'
>
>
> Still trying. I must be doing something wrong… :-(
>
> Cheers,
> =David
>
>

Re: Bndtools & Karaf : the right way

Hi David,

let me check, but I think we already have a Jira about that (actually, 
we already discussed about that with Christian and Guillaume).

Regards
JB

On 11/30/2015 08:41 AM, David Leangen wrote:

>> There is an easy way to install bundles.
>> Just use the feature:requirement-add command.

Sounds practical. But then again, I really like the idea of
“features”. I like to see which “feature” is installed and
running. If my bundle is only added as a requirement, then I lose
that visibility. Also, having to restart Karaf each time I want to
add a new repository (as is currently the case) is not a very nice
option for me.

Jean-Baptiste is working on that.
I've also pushed support for referencing xml repositories from
features files to a github branch
https://github.com/gnodet/karaf/tree/KARAF-4130

Looks nice!

I noticed that currently, it is not possible to add a new Feature via
the FeatureService. Although there is an addFeature(Feature) type method
in the API, in practice it will not work if there is not a corresponding
XML repo.

It would be very nice to be able to create a feature on the fly, such as
by wrapping a bundle, then add it via the service. Actually, for what I
am trying to do it would be “necessary”. :-)

Should I file a JIRA issue for this?

In any case, feature:requirement-add is currently not working for
me, for 2 reasons…

1) The patch I submitted to allow resolution of resources with
relative URLs only works when
 there is one single Repository added to the config file. I am
investigating an updated fix, but:

2) Something odd happens intermittently when I try to add a
requirement. Karaf adds “type=karaf.feature”
 even when I express the type as “osgi.bundle”. Example:

karaf@root()> feature:requirement-add
‘osgi.identity=my.bundle;type=osgi.bundle'
Error executing command: Unable to resolve root: missing
requirement [root] osgi.identity;
osgi.identity=“osgi.identity=my.bundle;type=osgi.bundle";
type=karaf.feature;

filter:="(&(osgi.identity=osgi.identity=my.bundle;type=osgi.bundle)(type=karaf.feature))”

Try with feature:requirement-add
‘requirement:osgi.identity;osgi.identity=my.bundle;type=osgi.bundle'

Still trying. I must be doing something wrong… :-(

Cheers,
=David

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

Re: Bndtools & Karaf : the right way

David wants to create a "dummy bundle", describing a feature as 
resources (without the XML).

Not yet sure it's a good idea (it's what we discussed on IRC).

Regards
JB

On 11/30/2015 10:36 AM, Guillaume Nodet wrote:

2015-11-30 8:41 GMT+01:00 David Leangen >:

>> There is an easy way to install bundles.
>> Just use the feature:requirement-add command.

Sounds practical. But then again, I really like the idea of
“features”. I like to see which “feature” is installed and
running. If my bundle is only added as a requirement, then I
lose that visibility. Also, having to restart Karaf each time
I want to add a new repository (as is currently the case) is
not a very nice option for me.

Jean-Baptiste is working on that.
I've also pushed support for referencing xml repositories from
features files to a github branch
https://github.com/gnodet/karaf/tree/KARAF-4130

Looks nice!

I noticed that currently, it is not possible to add a new Feature
via the FeatureService. Although there is an addFeature(Feature)
type method in the API, in practice it will not work if there is not
a corresponding XML repo.

It would be very nice to be able to create a feature on the fly,
such as by wrapping a bundle, then add it via the service. Actually,
for what I am trying to do it would be “necessary”. :-)

I'm not sure i understand this requirement.  How can you
programmatically generate the feature definition ? What's your input
exactly ?

Should I file a JIRA issue for this?

In any case, feature:requirement-add is currently not working
for me, for 2 reasons…

1) The patch I submitted to allow resolution of resources with
relative URLs only works when
 there is one single Repository added to the config file.
I am investigating an updated fix, but:

2) Something odd happens intermittently when I try to add a
requirement. Karaf adds “type=karaf.feature”
 even when I express the type as “osgi.bundle”. Example:

karaf@root()> feature:requirement-add
‘osgi.identity=my.bundle;type=osgi.bundle'
Error executing command: Unable to resolve root: missing
requirement [root] osgi.identity;
osgi.identity=“osgi.identity=my.bundle;type=osgi.bundle";
type=karaf.feature;

filter:="(&(osgi.identity=osgi.identity=my.bundle;type=osgi.bundle)(type=karaf.feature))”

Try with feature:requirement-add
‘requirement:osgi.identity;osgi.identity=my.bundle;type=osgi.bundle'

Still trying. I must be doing something wrong… :-(

Cheers,
=David

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

Re: Bndtools & Karaf : the right way

It would be easier to start from the real requirements rather than from a
possible solution...

David, could you briefly outline what you want to achieve without going
into a possible solution ?

2015-11-30 10:40 GMT+01:00 Jean-Baptiste Onofré :

> David wants to create a "dummy bundle", describing a feature as resources
> (without the XML).
>
> Not yet sure it's a good idea (it's what we discussed on IRC).
>
> Regards
> JB
>
> On 11/30/2015 10:36 AM, Guillaume Nodet wrote:
>
>>
>>
>> 2015-11-30 8:41 GMT+01:00 David Leangen > >:
>>
>>
>>
>> >> There is an easy way to install bundles.
>>> >> Just use the feature:requirement-add command.
>>>
>>> Sounds practical. But then again, I really like the idea of
>>> “features”. I like to see which “feature” is installed and
>>> running. If my bundle is only added as a requirement, then I
>>> lose that visibility. Also, having to restart Karaf each time
>>> I want to add a new repository (as is currently the case) is
>>> not a very nice option for me.
>>>
>>>
>>> Jean-Baptiste is working on that.
>>> I've also pushed support for referencing xml repositories from
>>> features files to a github branch
>>> https://github.com/gnodet/karaf/tree/KARAF-4130
>>>
>>
>> Looks nice!
>>
>> I noticed that currently, it is not possible to add a new Feature
>> via the FeatureService. Although there is an addFeature(Feature)
>> type method in the API, in practice it will not work if there is not
>> a corresponding XML repo.
>>
>> It would be very nice to be able to create a feature on the fly,
>> such as by wrapping a bundle, then add it via the service. Actually,
>> for what I am trying to do it would be “necessary”. :-)
>>
>>
>> I'm not sure i understand this requirement.  How can you
>> programmatically generate the feature definition ? What's your input
>> exactly ?
>>
>>
>> Should I file a JIRA issue for this?
>>
>>
>>
>> In any case, feature:requirement-add is currently not working
>>> for me, for 2 reasons…
>>>
>>> 1) The patch I submitted to allow resolution of resources with
>>> relative URLs only works when
>>>  there is one single Repository added to the config file.
>>> I am investigating an updated fix, but:
>>>
>>> 2) Something odd happens intermittently when I try to add a
>>> requirement. Karaf adds “type=karaf.feature”
>>>  even when I express the type as “osgi.bundle”. Example:
>>>
>>> karaf@root()> feature:requirement-add
>>> ‘osgi.identity=my.bundle;type=osgi.bundle'
>>> Error executing command: Unable to resolve root: missing
>>> requirement [root] osgi.identity;
>>> osgi.identity=“osgi.identity=my.bundle;type=osgi.bundle";
>>> type=karaf.feature;
>>>
>>> filter:="(&(osgi.identity=osgi.identity=my.bundle;type=osgi.bundle)(type=karaf.feature))”
>>>
>>>
>>> Try with feature:requirement-add
>>> ‘requirement:osgi.identity;osgi.identity=my.bundle;type=osgi.bundle'
>>>
>>
>> Still trying. I must be doing something wrong… :-(
>>
>> Cheers,
>> =David
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Bndtools & Karaf : the right way


> Anyway, once I'm given a repository and a set of bundles to look at, i'm 
> willing to look at it.

Cool! Thank you very much!

I will work on that as soon as I can. :-)

Cheers,
=David

Re: Bndtools & Karaf : the right way

2015-11-29 Thread David Leangen


> >> There is an easy way to install bundles.
> >> Just use the feature:requirement-add command.
> 
> Sounds practical. But then again, I really like the idea of “features”. I 
> like to see which “feature” is installed and running. If my bundle is only 
> added as a requirement, then I lose that visibility. Also, having to restart 
> Karaf each time I want to add a new repository (as is currently the case) is 
> not a very nice option for me.
> 
> Jean-Baptiste is working on that.
> I've also pushed support for referencing xml repositories from features files 
> to a github branch
>https://github.com/gnodet/karaf/tree/KARAF-4130 
> 
Looks nice!

I noticed that currently, it is not possible to add a new Feature via the 
FeatureService. Although there is an addFeature(Feature) type method in the 
API, in practice it will not work if there is not a corresponding XML repo.

It would be very nice to be able to create a feature on the fly, such as by 
wrapping a bundle, then add it via the service. Actually, for what I am trying 
to do it would be “necessary”. :-)

Should I file a JIRA issue for this?



> In any case, feature:requirement-add is currently not working for me, for 2 
> reasons…
> 
> 1) The patch I submitted to allow resolution of resources with relative URLs 
> only works when
>  there is one single Repository added to the config file. I am 
> investigating an updated fix, but:
> 
> 2) Something odd happens intermittently when I try to add a requirement. 
> Karaf adds “type=karaf.feature”
>  even when I express the type as “osgi.bundle”. Example:
> 
> karaf@root()> feature:requirement-add 
> ‘osgi.identity=my.bundle;type=osgi.bundle'
> Error executing command: Unable to resolve root: missing requirement [root] 
> osgi.identity; osgi.identity=“osgi.identity=my.bundle;type=osgi.bundle"; 
> type=karaf.feature; 
> filter:="(&(osgi.identity=osgi.identity=my.bundle;type=osgi.bundle)(type=karaf.feature))”
> 
> 
> Try with feature:requirement-add 
> ‘requirement:osgi.identity;osgi.identity=my.bundle;type=osgi.bundle'

Still trying. I must be doing something wrong… :-(

Cheers,
=David

Re: Bndtools & Karaf : the right way

2015-11-28 Thread Guillaume Nodet

2015-11-28 8:45 GMT+01:00 David Leangen :

>
> Hi!
>
> >> There is an easy way to install bundles.
> >> Just use the feature:requirement-add command.
>
> Sounds practical. But then again, I really like the idea of “features”. I
> like to see which “feature” is installed and running. If my bundle is only
> added as a requirement, then I lose that visibility. Also, having to
> restart Karaf each time I want to add a new repository (as is currently the
> case) is not a very nice option for me.
>

Jean-Baptiste is working on that.
I've also pushed support for referencing xml repositories from features
files to a github branch
   https://github.com/gnodet/karaf/tree/KARAF-4130


>
> In any case, feature:requirement-add is currently not working for me, for
> 2 reasons…
>
> 1) The patch I submitted to allow resolution of resources with relative
> URLs only works when
>  there is one single Repository added to the config file. I am
> investigating an updated fix, but:
>
> 2) Something odd happens intermittently when I try to add a requirement.
> Karaf adds “type=karaf.feature”
>  even when I express the type as “osgi.bundle”. Example:
>
> karaf@root()> feature:requirement-add
> ‘osgi.identity=my.bundle;type=osgi.bundle'
> Error executing command: Unable to resolve root: missing requirement
> [root] osgi.identity;
> osgi.identity=“osgi.identity=my.bundle;type=osgi.bundle";
> type=karaf.feature;
> filter:="(&(osgi.identity=osgi.identity=my.bundle;type=osgi.bundle)(type=karaf.feature))”
>
>
Try with feature:requirement-add
‘requirement:osgi.identity;osgi.identity=my.bundle;type=osgi.bundle'


> That filter is very odd, considering that (1) there is no such feature,
> and (2) that is not what I asked for.
>
> I tried stepping my way through the code to understand what is happening,
> but I am finding it very difficult to navigate. There is too much
> complexity IMHO and not enough clarity, at least for an outsider like me.
>
> > You can use the feature service, to install the "top level" feature
> containing the requirements. Then the resolver will install all bundles
> needed from the OBR repo.
>
> I tried this, but unfortunately it appears it won’t work without some more
> updates to Karaf.
>
> Problems:
> * Added features throws an error if it cannot be corresponded to an
> existing “features repository”
> * It seems that currently the ONLY way to add a features repository is by
> having an actual xml file
>(i.e. it cannot be constructed in runtime without artificially creating
> an xml file just to satisfy the above constraint)
>
> I am investigating this more now, but if you have any hints, that would be
> great.
>
> > To be completely in the line of the feature service it would probably
> also be possible to create a kind of wrapper feature just with the one
> bundle to pull up the rest.
> > So bndtools could be used to define everything besides the wrapper
> feature but that would be no big issue as it is quite trivial.
>
> That would be perfect for my use case. That is in effect what I am
> currently trying to accomplish. I have just run into the above problems,
> though. Since I am not yet very used to the Karaf code base, it takes me a
> while to understand what is going on.
>
> I will continue to investigate this kind of wrapper, but any help would be
> greatly appreciated. You say this is "trivial", but since I don’t know the
> code well, it is taking me a really long time. :-)
>
>
> Cheers,
> =David

Re: Bndtools & Karaf : the right way

2015-11-27 Thread David Leangen


Hi!

>> There is an easy way to install bundles.
>> Just use the feature:requirement-add command.

Sounds practical. But then again, I really like the idea of “features”. I like 
to see which “feature” is installed and running. If my bundle is only added as 
a requirement, then I lose that visibility. Also, having to restart Karaf each 
time I want to add a new repository (as is currently the case) is not a very 
nice option for me.

In any case, feature:requirement-add is currently not working for me, for 2 
reasons…

1) The patch I submitted to allow resolution of resources with relative URLs 
only works when
 there is one single Repository added to the config file. I am 
investigating an updated fix, but:

2) Something odd happens intermittently when I try to add a requirement. Karaf 
adds “type=karaf.feature”
 even when I express the type as “osgi.bundle”. Example:

karaf@root()> feature:requirement-add ‘osgi.identity=my.bundle;type=osgi.bundle'
Error executing command: Unable to resolve root: missing requirement [root] 
osgi.identity; osgi.identity=“osgi.identity=my.bundle;type=osgi.bundle"; 
type=karaf.feature; 
filter:="(&(osgi.identity=osgi.identity=my.bundle;type=osgi.bundle)(type=karaf.feature))”

That filter is very odd, considering that (1) there is no such feature, and (2) 
that is not what I asked for.

I tried stepping my way through the code to understand what is happening, but I 
am finding it very difficult to navigate. There is too much complexity IMHO and 
not enough clarity, at least for an outsider like me.

> You can use the feature service, to install the "top level" feature 
> containing the requirements. Then the resolver will install all bundles 
> needed from the OBR repo.

I tried this, but unfortunately it appears it won’t work without some more 
updates to Karaf.

Problems:
* Added features throws an error if it cannot be corresponded to an existing 
“features repository”
* It seems that currently the ONLY way to add a features repository is by 
having an actual xml file
   (i.e. it cannot be constructed in runtime without artificially creating an 
xml file just to satisfy the above constraint)

I am investigating this more now, but if you have any hints, that would be 
great.

> To be completely in the line of the feature service it would probably also be 
> possible to create a kind of wrapper feature just with the one bundle to pull 
> up the rest.
> So bndtools could be used to define everything besides the wrapper feature 
> but that would be no big issue as it is quite trivial.

That would be perfect for my use case. That is in effect what I am currently 
trying to accomplish. I have just run into the above problems, though. Since I 
am not yet very used to the Karaf code base, it takes me a while to understand 
what is going on.

I will continue to investigate this kind of wrapper, but any help would be 
greatly appreciated. You say this is "trivial", but since I don’t know the code 
well, it is taking me a really long time. :-)


Cheers,
=David

Re: Bndtools & Karaf : the right way

Sounds interesting.

If the obr commands are deprecated then I agree that the feature service
is the path to go. I just was not aware that

you can install something without defining a feature.

To be completely in the line of the feature service it would probably
also be possible to create a kind of wrapper feature just with the one
bundle to pull up the rest.
So bndtools could be used to define everything besides the wrapper
feature but that would be no big issue as it is quite trivial.

Christian

Am 26.11.2015 um 17:48 schrieb Guillaume Nodet:

There is an easy way to install bundles.
Just use the feature:requirement-add command.

feature:requirement-add
'requirement:osgi.identity;osgi.identity=org.apache.aries.blueprint.core;type=osgi.bundle;version="[1,2)"'

Guillaume

2015-11-26 14:40 GMT+01:00 Christian Schneider
>:

We are currently discussing this on the karaf irc.
As the long term solutions are not yet ready I would use a
practical approach for now.

How about creating a feature with a list of bundles out of the
-runbundles that bndtools creates?
That would then not even require a repository.

Christian

On 26.11.2015 14:29, David Leangen wrote:

Hi Christian,

Thank you very much for this discussion. It is very interesting
(and educational) since it is relevant to my current top
priority: getting our development—> deployment pipeline up and
running quickly.

Getting back to more immediate practical matters…

Given that there is not currently a bnd plugin to create a
features file, and since I do not want to head in a solitary
direction, what do you recommend I do to automate the generation
/ installation of my features?

What I have:
* OBR repositories “deployed” by the devs, which are handed over
to the deployer
* A Karaf command for the deployer to browse the available OBR repos

What I need:
* A means to actually install and start the bundles

I don’t mind doing this against the Features service in runtime,
since I am building a “deployment” service anyway, to be used by
the deployer.

Any thoughts to help me get up and running quickly would be very
welcome. :-)

Cheers,
=David

--
Christian Schneider

http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Bndtools & Karaf : the right way

2015-11-26 21:07 GMT+01:00 Christian Schneider :

> Sounds interesting.
>
> If the obr commands are deprecated then I agree that the feature service
> is the path to go.
>

They can be used, but they are far inferior to the feature:xxx commands.


> I just was not aware that
> you can install something without defining a feature.
>

Fwiw, the input to the features deployer is mainly a Map.

The key is the region to install the requirements to (usually "root", the
default region).  The set is a set of requirements.   Those requirements
are either:
   feature:feature-name[/version-range]
   requirement:osgi-requirement
   bundle:bundle-url

The bundle:xxx will force the installation of the given bundle using the
resolver (so solving all its requirements as usual).  For the discussed use
case, the drawback is that is uses the bundle url and not the symbolic name
/ version, but you can always fall back to the requirement syntax for that.

Another input to the resolver is the desired features state (installed /
resolver / started) for each feature, in case you want to manage stopped
features.


>
> To be completely in the line of the feature service it would probably also
> be possible to create a kind of wrapper feature just with the one bundle to
> pull up the rest.
>
So bndtools could be used to define everything besides the wrapper feature
> but that would be no big issue as it is quite trivial.
>
> Christian
>
>
> Am 26.11.2015 um 17:48 schrieb Guillaume Nodet:
>
> There is an easy way to install bundles.
> Just use the feature:requirement-add command.
>
> feature:requirement-add
> 'requirement:osgi.identity;osgi.identity=org.apache.aries.blueprint.core;type=osgi.bundle;version="[1,2)"'
>
>
> Guillaume
>
>
>
> 2015-11-26 14:40 GMT+01:00 Christian Schneider :
>
>> We are currently discussing this on the karaf irc.
>> As the long term solutions are not yet ready I would use a practical
>> approach for now.
>>
>> How about creating a feature with a list of bundles out of the
>> -runbundles that bndtools creates?
>> That would then not even require a repository.
>>
>> Christian
>>
>> On 26.11.2015 14:29, David Leangen wrote:
>>
>>
>> Hi Christian,
>>
>> Thank you very much for this discussion. It is very interesting (and
>> educational) since it is relevant to my current top priority: getting our
>> development—> deployment pipeline up and running quickly.
>>
>> Getting back to more immediate practical matters…
>>
>> Given that there is not currently a bnd plugin to create a features file,
>> and since I do not want to head in a solitary direction, what do you
>> recommend I do to automate the generation / installation of my features?
>>
>> What I have:
>>  * OBR repositories “deployed” by the devs, which are handed over to the
>> deployer
>>  * A Karaf command for the deployer to browse the available OBR repos
>>
>> What I need:
>>  * A means to actually install and start the bundles
>>
>>
>> I don’t mind doing this against the Features service in runtime, since I
>> am building a “deployment” service anyway, to be used by the deployer.
>>
>> Any thoughts to help me get up and running quickly would be very welcome.
>> :-)
>>
>>
>>
>> Cheers,
>> =David
>>
>>
>> --
>> Christian Schneiderhttp://www.liquid-reality.de
>>
>> Open Source Architecthttp://www.talend.com
>>
>>
>
>

Re: Bndtools & Karaf : the right way

2015-11-26 Thread Achim Nierbeck

Hi Richard,

as doing all my OSGi related work only in my private Time and working for a
Company not interested in OSGi, a 5k$ per year is hard to argue as
a "personal" invest. And yes in that case it's rather excessive!

regards, Achim


2015-11-26 8:26 GMT+01:00 Richard Nicholson :

> The OSGi Alliance exists because of the companies that step forward to
> fund it. Then - over and above this financial commitment - those same
> companies actively put engineering resources into drive OSGi
> specifications, CT’s & RI’s - many of which are then used by the OSS world
> including this community.
>
> We do have a program for non-commercial Academic Institutions. But
> commercial organisations do need to pay their dues.
>
> For reference, we are only talking $5K a year for Contributing Associate.
> Hardly excessive?
>
> Best Wishes
>
> Richard
>
>
> > On 26 Nov 2015, at 07:03, Jean-Baptiste Onofré  wrote:
> >
> > As a company, I know that it's simple. I'm talking with the Talend
> board, but unfortunately, I'm not sure that Talend would be interested to
> participate in the OSGi Alliance.
> >
> > Maybe we can talk together about the "personal participation" related to
> OpenSource/Apache projects.
> >
> > WDYT ?
> >
> > Regards
> > JB
> >
> > On 11/26/2015 07:59 AM, Richard Nicholson wrote:
> >> Jean-Baptist
> >>
> >> Re: Joining the OSGi Alliance is simple. I’d be happy to walk your
> Talend management through the process.
> >>
> >> Best Wishes
> >>
> >> Richard
> >>
> >>
> >>
> >>> On 26 Nov 2015, at 06:51, Jean-Baptiste Onofré 
> wrote:
> >>>
> >>> Hi David,
> >>>
> >>> We created features instead of using directly OBR as OBR doesn't cover
> the needs (features contain transitive features, configuration, bundles,
> etc). Generating a feature from OBR repository will result to incomplete
> and limited features IMHO.
> >>>
> >>> As bndtools is a design/development time, I would prefer that it can
> generate a complete feature.
> >>>
> >>> I agree that a spec enhancement, containing a mix feature (as a
> generic OSGi feature), subsystem, OSGi Repositories (new name of OBR) can
> be interesting.
> >>> As I said in another e-mail, I would be more than happy to
> participate, but as Apache is not a company and can't pay the OSGi
> Alliance, it's not easy for us to be part of the OSGi Alliance (other than
> being employee of a company already member of the OSGi Alliance).
> >>>
> >>> Regard
> >>> JB
> >>>
> >>> On 11/26/2015 07:13 AM, David Leangen wrote:
> 
>  Hi JB,
> 
>  If a plugin is required to create a features set for each development
>  environment, that would probably create a lot of extra work.
> 
>  If instead a features set could be generated from a generic OBR
>  repository, then the solution would be generalised to any development
>  environment. Instead of Karaf features being something totally
>  different, it would instead be layered on top of the OBR spec. I think
>  adding a “karaf feature” capability to one or more bundles in a
>  repository not only makes sense, but is exactly the purpose of the
> whole
>  capability / requirement principle.
> 
>  At least, those are my thoughts…
> 
>  Also, when development, I would prefer to simply have one type of
>  (generic) output, rather than have to specialise my output depending
> on
>  the runtime environment. I can imagine a set of annotations that would
>  make feature creating really simple.
> 
>  Maybe this would be a candidate for a spec update, though I am getting
>  into very unknown territory, as I am by no means an expert in the
> OSGi spec.
> 
> 
>  My 2yen.
> 
>  Cheers,
>  =David
> 
> 
> 
>  On Nov 26, 2015, at 2:34 PM, Jean-Baptiste Onofré   > wrote:
> 
> > Hi David,
> >
> > It would be great if bndtools is able to "generate" the features.
> >
> > I know that Christian discussed with bndtools guys about that, and
> I'm
> > also jumping in bndtools to help.
> >
> > WDYT ?
> >
> > Regards
> > JB
> >
> > On 11/26/2015 01:36 AM, David Leangen wrote:
> >>
> >> Hi,
> >>
> >> If it’s any help, I am also using bndtools in Eclipse/gradle. I am
> in a
> >> greenfield environment, so it is probably easier for me.
> >>
> >> Thanks to the help of the kind people in this community, I was able
> to
> >> get my release process working. I do this by releasing my bundles
> from
> >> bndtools, then having Karaf pull in the bundles from that
> repository. I
> >> actually like this way of passing the baton, as it nicely decouples
> my
> >> development environment from my deployment environment, using the
> >> standard OBR repository as the intermediary.
> >>
> >> My only remaining challenge is, since Karaf

Re: Bndtools & Karaf : the right way

I agree with JB. It would be great if the foundation would also allow 
more individuals to participate in the specification work.
In the open source world there is lots of expertise around OSGi that can 
be leveraged.


For JB and me the problem is that we (till now) can not convince our 
company to become a member. Honestly I think this is sad as the money is 
clearly not the big issue.
On the other hand we would be able to kind of sponsor part of our time 
to work on specifications. Interestingly this is less of an issue at 
Talend as it is decided on another management level.


Christian

On 26.11.2015 08:37, Jean-Baptiste Onofré wrote:

Hi Richard,

it's not excessive for sure, it's more kind of "direction concern" for 
Talend. I'm dealing with the Talend board to convince (I have a 
meeting about that the second week of December), we will see.


The point is more kind of person involvement: what happens if "OSGi 
people" leaves the company to another one. It means that the "new 
company" has to become "OSGi member".


Not a big deal, but it could be great to have non-commercial/Apache 
agreement somehow maybe.


Regards
JB

On 11/26/2015 08:26 AM, Richard Nicholson wrote:
The OSGi Alliance exists because of the companies that step forward 
to fund it. Then - over and above this financial commitment - those 
same companies actively put engineering resources into drive OSGi 
specifications, CT’s & RI’s - many of which are then used by the OSS 
world including this community.


We do have a program for non-commercial Academic Institutions. But 
commercial organisations do need to pay their dues.


For reference, we are only talking $5K a year for Contributing 
Associate. Hardly excessive?


Best Wishes

Richard



On 26 Nov 2015, at 07:03, Jean-Baptiste Onofré  wrote:

As a company, I know that it's simple. I'm talking with the Talend 
board, but unfortunately, I'm not sure that Talend would be 
interested to participate in the OSGi Alliance.


Maybe we can talk together about the "personal participation" 
related to OpenSource/Apache projects.


WDYT ?

Regards
JB

On 11/26/2015 07:59 AM, Richard Nicholson wrote:

Jean-Baptist

Re: Joining the OSGi Alliance is simple. I’d be happy to walk your 
Talend management through the process.


Best Wishes

Richard



On 26 Nov 2015, at 06:51, Jean-Baptiste Onofré  
wrote:


Hi David,

We created features instead of using directly OBR as OBR doesn't 
cover the needs (features contain transitive features, 
configuration, bundles, etc). Generating a feature from OBR 
repository will result to incomplete and limited features IMHO.


As bndtools is a design/development time, I would prefer that it 
can generate a complete feature.


I agree that a spec enhancement, containing a mix feature (as a 
generic OSGi feature), subsystem, OSGi Repositories (new name of 
OBR) can be interesting.
As I said in another e-mail, I would be more than happy to 
participate, but as Apache is not a company and can't pay the OSGi 
Alliance, it's not easy for us to be part of the OSGi Alliance 
(other than being employee of a company already member of the OSGi 
Alliance).


Regard
JB

On 11/26/2015 07:13 AM, David Leangen wrote:


Hi JB,

If a plugin is required to create a features set for each 
development

environment, that would probably create a lot of extra work.

If instead a features set could be generated from a generic OBR
repository, then the solution would be generalised to any 
development

environment. Instead of Karaf features being something totally
different, it would instead be layered on top of the OBR spec. I 
think

adding a “karaf feature” capability to one or more bundles in a
repository not only makes sense, but is exactly the purpose of 
the whole

capability / requirement principle.

At least, those are my thoughts…

Also, when development, I would prefer to simply have one type of
(generic) output, rather than have to specialise my output 
depending on
the runtime environment. I can imagine a set of annotations that 
would

make feature creating really simple.

Maybe this would be a candidate for a spec update, though I am 
getting
into very unknown territory, as I am by no means an expert in the 
OSGi spec.



My 2yen.

Cheers,
=David



On Nov 26, 2015, at 2:34 PM, Jean-Baptiste Onofré > wrote:


Hi David,

It would be great if bndtools is able to "generate" the features.

I know that Christian discussed with bndtools guys about that, 
and I'm

also jumping in bndtools to help.

WDYT ?

Regards
JB

On 11/26/2015 01:36 AM, David Leangen wrote:


Hi,

If it’s any help, I am also using bndtools in Eclipse/gradle. I 
am in a

greenfield environment, so it is probably easier for me.

Thanks to the help of the kind people in this community, I was 
able to
get my release process working. I do this by releasing my 
bundles from
bndtools, then having Karaf pull in the bundles from that

Re: Bndtools & Karaf : the right way

2015-11-26 Thread Richard Nicholson

Christian,

If OSGi Alliance membership fee isn’t the issue - and time contributed by 
engineers isn’t the issue - then if your management could reach out the me and 
explain the problem I’d happily look into it.

As CEO of Paremus - my primary consideration is the cost of membership (Paremus 
are Strategic Members) and the time my engineers spend on OSGi Alliance 
activities & Bndtools which we also lead, 

So I’m genuinely curious and willing to help. 

Best

Richard


> On 26 Nov 2015, at 08:19, Christian Schneider  wrote:
> 
> I agree with JB. It would be great if the foundation would also allow more 
> individuals to participate in the specification work.
> In the open source world there is lots of expertise around OSGi that can be 
> leveraged.
> 
> For JB and me the problem is that we (till now) can not convince our company 
> to become a member. Honestly I think this is sad as the money is clearly not 
> the big issue.
> On the other hand we would be able to kind of sponsor part of our time to 
> work on specifications. Interestingly this is less of an issue at Talend as 
> it is decided on another management level.
> 
> Christian
> 
> On 26.11.2015 08:37, Jean-Baptiste Onofré wrote:
>> Hi Richard,
>> 
>> it's not excessive for sure, it's more kind of "direction concern" for 
>> Talend. I'm dealing with the Talend board to convince (I have a meeting 
>> about that the second week of December), we will see.
>> 
>> The point is more kind of person involvement: what happens if "OSGi people" 
>> leaves the company to another one. It means that the "new company" has to 
>> become "OSGi member".
>> 
>> Not a big deal, but it could be great to have non-commercial/Apache 
>> agreement somehow maybe.
>> 
>> Regards
>> JB
>> 
>> On 11/26/2015 08:26 AM, Richard Nicholson wrote:
>>> The OSGi Alliance exists because of the companies that step forward to fund 
>>> it. Then - over and above this financial commitment - those same companies 
>>> actively put engineering resources into drive OSGi specifications, CT’s & 
>>> RI’s - many of which are then used by the OSS world including this 
>>> community.
>>> 
>>> We do have a program for non-commercial Academic Institutions. But 
>>> commercial organisations do need to pay their dues.
>>> 
>>> For reference, we are only talking $5K a year for Contributing Associate. 
>>> Hardly excessive?
>>> 
>>> Best Wishes
>>> 
>>> Richard
>>> 
>>> 
 On 26 Nov 2015, at 07:03, Jean-Baptiste Onofré  wrote:
 
 As a company, I know that it's simple. I'm talking with the Talend board, 
 but unfortunately, I'm not sure that Talend would be interested to 
 participate in the OSGi Alliance.
 
 Maybe we can talk together about the "personal participation" related to 
 OpenSource/Apache projects.
 
 WDYT ?
 
 Regards
 JB
 
 On 11/26/2015 07:59 AM, Richard Nicholson wrote:
> Jean-Baptist
> 
> Re: Joining the OSGi Alliance is simple. I’d be happy to walk your Talend 
> management through the process.
> 
> Best Wishes
> 
> Richard
> 
> 
> 
>> On 26 Nov 2015, at 06:51, Jean-Baptiste Onofré  wrote:
>> 
>> Hi David,
>> 
>> We created features instead of using directly OBR as OBR doesn't cover 
>> the needs (features contain transitive features, configuration, bundles, 
>> etc). Generating a feature from OBR repository will result to incomplete 
>> and limited features IMHO.
>> 
>> As bndtools is a design/development time, I would prefer that it can 
>> generate a complete feature.
>> 
>> I agree that a spec enhancement, containing a mix feature (as a generic 
>> OSGi feature), subsystem, OSGi Repositories (new name of OBR) can be 
>> interesting.
>> As I said in another e-mail, I would be more than happy to participate, 
>> but as Apache is not a company and can't pay the OSGi Alliance, it's not 
>> easy for us to be part of the OSGi Alliance (other than being employee 
>> of a company already member of the OSGi Alliance).
>> 
>> Regard
>> JB
>> 
>> On 11/26/2015 07:13 AM, David Leangen wrote:
>>> 
>>> Hi JB,
>>> 
>>> If a plugin is required to create a features set for each development
>>> environment, that would probably create a lot of extra work.
>>> 
>>> If instead a features set could be generated from a generic OBR
>>> repository, then the solution would be generalised to any development
>>> environment. Instead of Karaf features being something totally
>>> different, it would instead be layered on top of the OBR spec. I think
>>> adding a “karaf feature” capability to one or more bundles in a
>>> repository not only makes sense, but is exactly the purpose of the whole
>>> capability / requirement principle.
>>> 
>>> At least, those are my thoughts…
>>> 
>>>

Re: Bndtools & Karaf : the right way


On 26.11.2015 08:52, David Leangen wrote:



Then perhaps all we need to do is allow a Feature to include an OBR 
repo as an option.


Bundles in the feature could provide a capability (for example in the 
“namespace=karaf.feature”) to flag it as a bundle to be included in 
the feature.

Re: Bndtools & Karaf : the right way


Hi Richard,

thank you so much. Let me contact you directly and plan a call second 
week of December if you are available.


Thank again,
Regards
JB

On 11/26/2015 09:28 AM, Richard Nicholson wrote:

Christian,

If OSGi Alliance membership fee isn’t the issue - and time contributed
by engineers isn’t the issue - then if your management could reach out
the me and explain the problem I’d happily look into it.

As CEO of Paremus - my primary consideration is the cost of membership
(Paremus are Strategic Members) and the time my engineers spend on OSGi
Alliance activities & Bndtools which we also lead,

So I’m genuinely curious and willing to help.

Best

Richard



On 26 Nov 2015, at 08:19, Christian Schneider > wrote:

I agree with JB. It would be great if the foundation would also allow
more individuals to participate in the specification work.
In the open source world there is lots of expertise around OSGi that
can be leveraged.

For JB and me the problem is that we (till now) can not convince our
company to become a member. Honestly I think this is sad as the money
is clearly not the big issue.
On the other hand we would be able to kind of sponsor part of our time
to work on specifications. Interestingly this is less of an issue at
Talend as it is decided on another management level.

Christian

On 26.11.2015 08:37, Jean-Baptiste Onofré wrote:

Hi Richard,

it's not excessive for sure, it's more kind of "direction concern"
for Talend. I'm dealing with the Talend board to convince (I have a
meeting about that the second week of December), we will see.

The point is more kind of person involvement: what happens if "OSGi
people" leaves the company to another one. It means that the "new
company" has to become "OSGi member".

Not a big deal, but it could be great to have non-commercial/Apache
agreement somehow maybe.

Regards
JB

On 11/26/2015 08:26 AM, Richard Nicholson wrote:

The OSGi Alliance exists because of the companies that step forward
to fund it. Then - over and above this financial commitment - those
same companies actively put engineering resources into drive OSGi
specifications, CT’s & RI’s - many of which are then used by the OSS
world including this community.

We do have a program for non-commercial Academic Institutions. But
commercial organisations do need to pay their dues.

For reference, we are only talking $5K a year for Contributing
Associate. Hardly excessive?

Best Wishes

Richard



On 26 Nov 2015, at 07:03, Jean-Baptiste Onofré > wrote:

As a company, I know that it's simple. I'm talking with the Talend
board, but unfortunately, I'm not sure that Talend would be
interested to participate in the OSGi Alliance.

Maybe we can talk together about the "personal participation"
related to OpenSource/Apache projects.

WDYT ?

Regards
JB

On 11/26/2015 07:59 AM, Richard Nicholson wrote:

Jean-Baptist

Re: Joining the OSGi Alliance is simple. I’d be happy to walk your
Talend management through the process.

Best Wishes

Richard




On 26 Nov 2015, at 06:51, Jean-Baptiste Onofré > wrote:

Hi David,

We created features instead of using directly OBR as OBR doesn't
cover the needs (features contain transitive features,
configuration, bundles, etc). Generating a feature from OBR
repository will result to incomplete and limited features IMHO.

As bndtools is a design/development time, I would prefer that it
can generate a complete feature.

I agree that a spec enhancement, containing a mix feature (as a
generic OSGi feature), subsystem, OSGi Repositories (new name of
OBR) can be interesting.
As I said in another e-mail, I would be more than happy to
participate, but as Apache is not a company and can't pay the
OSGi Alliance, it's not easy for us to be part of the OSGi
Alliance (other than being employee of a company already member
of the OSGi Alliance).

Regard
JB

On 11/26/2015 07:13 AM, David Leangen wrote:


Hi JB,

If a plugin is required to create a features set for each
development
environment, that would probably create a lot of extra work.

If instead a features set could be generated from a generic OBR
repository, then the solution would be generalised to any
development
environment. Instead of Karaf features being something totally
different, it would instead be layered on top of the OBR spec. I
think
adding a “karaf feature” capability to one or more bundles in a
repository not only makes sense, but is exactly the purpose of
the whole
capability / requirement principle.

At least, those are my thoughts…

Also, when development, I would prefer to simply have one type of
(generic) output, rather than have to specialise my output
depending on
the runtime environment. I can imagine a set of annotations that
would
make feature creating really simple.

Maybe this would be a candidate for a spec update, though I am
getting
into very unknown

Re: Bndtools & Karaf : the right way


I agree with Christian.

We already have a Jira about that as Christian and I discussed about that.

The purpose is to first have repository/index XML references in a 
features XML.


Regards
JB

On 11/26/2015 09:52 AM, Christian Schneider wrote:

On 26.11.2015 08:52, David Leangen wrote:



Then perhaps all we need to do is allow a Feature to include an OBR
repo as an option.

Bundles in the feature could provide a capability (for example in the
“namespace=karaf.feature”) to flag it as a bundle to be included in
the feature.

Re: Bndtools & Karaf : the right way

Just a few points I want to mention in this discussion.

The karaf deployer uses the OSGi resolver.  Features are modelled into OSGi
resources, the exact same way as bundles, so they can easily be written
with the standard xml description.  It's just a matter of writing back
resource generated from the feature as an xml (and the code already exists).
See

https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/resolver/FeatureResource.java#L48-L71

I agree the xml repository would be better placed as a top level element,
along feature repositories.

As for deployment, I haven't seen how "bnd applications" are modelled, but
the karaf deployer can be given abstract requirements.  When one installs a
feature, it's simply translated into a new requirement that point to this
feature.

https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/resolver/ResourceUtils.java#L169-L180

Guillaume



2015-11-26 9:52 GMT+01:00 Christian Schneider :

> On 26.11.2015 08:52, David Leangen wrote:
>
>
>
> Then perhaps all we need to do is allow a Feature to include an OBR repo
> as an option.
>
> Bundles in the feature could provide a capability (for example in the
> “namespace=karaf.feature”) to flag it as a bundle to be included in the
> feature.
>
> http://karaf.apache.org/xmlns/features/v1.3.0; name=“
> my-feature-set">
> 
> *
> http://host.com/path/to/repo/index.xml
> *
> 
> 
>
> I think it would make more sense to have the obr element on top level of
> the features xml as I think the obr repository would be that basis of all
> the features in the file.
>
> I have written down some ideas here some time ago:
>
> http://liquid-reality.de/display/liquid/Design+repository+based+features+for+Apache+Karaf
>
> Ideally we should work together on a complete design in an apache wiki so
> all can help.
>
>
> And in the OBR:
>
> http://www.osgi.org/xmlns/repository/v1.0.0; increment
> =“1" name="Release">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> ...
> **
> * " value=“name.of.feature/1.0.0"/>*
> **
> **
> *  *
> **
> **
>
> 
> 
> 
>
> ...
>
> 
> 
>
>
> I agree we would need to also bring the features into the OBR at some
> point. Karaf already uses a special capability to describe features
> internally to feed the resolver. We should be able to extend and
> standardize this.
>
> As karaf features are proprietary we might be able to use subsystem
> descriptors (in their feature mode). In fact they look a lot like bndrun
> files already. So maybe the subsystem spec could be enhanced to cover that
> case.
>
> (Not sure if the attributes should be there or not, just added them in as
> an afterthought.)
>
> In any case, all the bundle information etc. is already there, so it seems
> unnecessary to have to duplicate it in in a features.xml file.
>
> I think it would not be a good idea to use an OBR repository to describe a
> feature. An OBR repository is more like the target platform in eclipse PDE.
> It defines which bundles are available and what they provide and need.
> The feature should then define the requirements to help the resolver
> decide which bundles from the repository to combine to make the feature
> resolvable. This is then very similar to a bndrun file.
>
> The main question here is how to define that a feature might depend on
> another feature. Bndtools currently does not have this concept in its
> bndrun files. I think one possibility would be to define such a dependency
> as a requirement on a feature.
>
>
> As bndtools is a design/development time, I would prefer that it can
> generate a complete feature.
>
>
> For the application mode a it makes sense that bndtools creates a complete
> deployment (probably even including the needed karaf internal features).
> For the server mode the features would be just requirements + refrence to
> OBR repository and the karaf resolver would build the actual list of
> bundles at runtime.
>
> I understand.
>
> This does not really fit our model well and, if I am understanding the
> intent of OSGi, not that model, either.
>
> I believe that OSGi presumes that the bundle developer is a different role
> from the operator. I would argue that the creation of features is an
> operator function, not a bundle developer function.
>
> Normally an operator/admin does not want to be too much involved into the
> definition of the features. So I think this should be part of the
> development process. The operator would be just given the deployment unit
> with the instructions how to install it.
>
>
> In my specific use case, I am considering having a “deployment” service
> read the available OBR repositories, and provide deployment options to the
> operator at (deployment) runtime. What I think would be easy to do is to
> read the OBR repositories and, one way or

Re: Bndtools & Karaf : the right way


> I have written down some ideas here some time ago:
> http://liquid-reality.de/display/liquid/Design+repository+based+features+for+Apache+Karaf
>  
> 
Very nice !

> I agree we would need to also bring the features into the OBR at some point. 
> Karaf already uses a special capability to describe features internally to 
> feed the resolver. We should be able to extend and standardize this.

Great!

Currently, when I deploy bundles from the dev environment, if I also need a 
features.xml file, then it needs to be shipped together with the OBR as part of 
my deployment package. My repo then looks something like this:

index.xml
index.xml.sha
features.xml
com.foo.bar/
…

It seems odd to me, and not DRY, that both index.xml and features.xml are 
provided in the same place like this. They seem to have very similar functions. 
So folding these into the OBR itself sounds right to me.


>> I believe that OSGi presumes that the bundle developer is a different role 
>> from the operator. I would argue that the creation of features is an 
>> operator function, not a bundle developer function.
> Normally an operator/admin does not want to be too much involved into the 
> definition of the features.

I do not disagree!

> So I think this should be part of the development process. The operator would 
> be just given the deployment unit with the instructions how to install it. 

Perhaps, but I am not so sure.

I can envision, for instance, configuration parameters on 3 levels:

 1) default parameters (probably provided in the code)
  * reasonable defaults for a generalised environment
  * coded by the developer

 2) default parameters for a specific installation / runtime
  * system values for that particular environment
  * provided by the developer, IF the developer is part of the same team

 3) maintenance or operational parameters
  * stuff the operator needs to do to get and keep a system running
  * likely related to a particular machine (IP address, port numbers, disk 
usage…)

We are also toying with the idea of a “user operator” (kind of a support 
person, but who interfaces with the OSGi system) or something like that, 
meaning somebody who can install new users, help users fix problems during 
runtime, and so on.

The more expertise these operators require (such as OSGi / bundle-level 
knowledge) the costlier the system becomes.

To get back to the point… enRoute/bndtools seems to promote the idea of an 
“application bundle”, which pulls in all the required dependencies. If this 
bundle already provides everything I need to get a “feature” (in the general 
sense) up and running, then why all the extra cruft around it? All I need to do 
is detect this “application bundle(s)” in my OBR, and I can just pull in the 
other requirements. No?


Ok, instead of making a fool of myself on this list, maybe I should try out my 
ideas in the code first as a proof of concept. :-)


Cheers,
=David

Re: Bndtools & Karaf : the right way

Hi Guillaume,

as far as I know a bnd application is defined using a bndrun file and
one or more repositories.
So basically you define requirements and a bundle repository to resolve
against. Bndtools then creates the list of bundles interactively in the
eclipse bndtools UI. At build time you then already have the final list
of bundles.
I think this could be enhanced to also allow the resolve step to take
place at build time but as long as bndtools is doing the resolving we
probably would not notice the difference anyway on the karaf side.

For the features to work in bndtools as well as in karaf we would need
to define a common format to define a requirement that represents a
feature as well as to represent the content of a feature. Ideally I
think this should then be standardized at some point
so it can be used in a wider range of environments. Ultimately it would
be great to even find a common way together with the eclipse pde community.

Christian

Am 26.11.2015 um 10:16 schrieb Guillaume Nodet:

Just a few points I want to mention in this discussion.

The karaf deployer uses the OSGi resolver. Features are modelled into
OSGi resources, the exact same way as bundles, so they can easily be
written with the standard xml description. It's just a matter of
writing back resource generated from the feature as an xml (and the
code already exists).

See
https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/resolver/FeatureResource.java#L48-L71

I agree the xml repository would be better placed as a top level
element, along feature repositories.

As for deployment, I haven't seen how "bnd applications" are modelled,
but the karaf deployer can be given abstract requirements. When one
installs a feature, it's simply translated into a new requirement that
point to this feature.

https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/resolver/ResourceUtils.java#L169-L180

Guillaume

2015-11-26 9:52 GMT+01:00 Christian Schneider >:

On 26.11.2015 08:52, David Leangen wrote:

Then perhaps all we need to do is allow a Feature to include an
OBR repo as an option.

Bundles in the feature could provide a capability (for example in
the “namespace=karaf.feature”) to flag it as a bundle to be
included in the feature.

Re: Bndtools & Karaf : the right way

Do you have pointers about those "application bundles" ?

2015-11-26 10:59 GMT+01:00 David Leangen :

>
> I have written down some ideas here some time ago:
>
> http://liquid-reality.de/display/liquid/Design+repository+based+features+for+Apache+Karaf
>
>
> Very nice !
>
> I agree we would need to also bring the features into the OBR at some
> point. Karaf already uses a special capability to describe features
> internally to feed the resolver. We should be able to extend and
> standardize this.
>
>
> Great!
>
> Currently, when I deploy bundles from the dev environment, if I also need
> a features.xml file, then it needs to be shipped together with the OBR as
> part of my deployment package. My repo then looks something like this:
>
> index.xml
> index.xml.sha
> features.xml
> com.foo.bar/
> …
>
> It seems odd to me, and not DRY, that both index.xml and features.xml are
> provided in the same place like this. They seem to have very similar
> functions. So folding these into the OBR itself sounds right to me.
>
>
> I believe that OSGi presumes that the bundle developer is a different role
> from the operator. I would argue that the creation of features is an
> operator function, not a bundle developer function.
>
> Normally an operator/admin does not want to be too much involved into the
> definition of the features.
>
>
> I do not disagree!
>
> So I think this should be part of the development process. The operator
> would be just given the deployment unit with the instructions how to
> install it.
>
>
> Perhaps, but I am not so sure.
>
> I can envision, for instance, configuration parameters on 3 levels:
>
>  1) default parameters (probably provided in the code)
>   * reasonable defaults for a generalised environment
>   * coded by the developer
>
>  2) default parameters for a specific installation / runtime
>   * system values for that particular environment
>   * provided by the developer, IF the developer is part of the same
> team
>
>  3) maintenance or operational parameters
>   * stuff the operator needs to do to get and keep a system running
>   * likely related to a particular machine (IP address, port numbers,
> disk usage…)
>
> We are also toying with the idea of a “user operator” (kind of a support
> person, but who interfaces with the OSGi system) or something like that,
> meaning somebody who can install new users, help users fix problems during
> runtime, and so on.
>
> The more expertise these operators require (such as OSGi / bundle-level
> knowledge) the costlier the system becomes.
>
> To get back to the point… enRoute/bndtools seems to promote the idea of an
> “application bundle”, which pulls in all the required dependencies. If this
> bundle already provides everything I need to get a “feature” (in the
> general sense) up and running, then why all the extra cruft around it? All
> I need to do is detect this “application bundle(s)” in my OBR, and I can
> just pull in the other requirements. No?
>
>
> Ok, instead of making a fool of myself on this list, maybe I should try
> out my ideas in the code first as a proof of concept. :-)
>
>
> Cheers,
> =David
>
>
>

Re: Bndtools & Karaf : the right way




Am 26.11.2015 um 10:59 schrieb David Leangen:

Perhaps, but I am not so sure.

I can envision, for instance, configuration parameters on 3 levels:

 1) default parameters (probably provided in the code)
  * reasonable defaults for a generalised environment
  * coded by the developer

 2) default parameters for a specific installation / runtime
  * system values for that particular environment
  * provided by the developer, IF the developer is part of the 
same team


 3) maintenance or operational parameters
  * stuff the operator needs to do to get and keep a system running
  * likely related to a particular machine (IP address, port 
numbers, disk usage…)


What you describe is a typical configuration problem especially when 
having different evnvironments like dev, test, prod which is absolutely 
common. Karaf does not yet provide a full solution for this. You can 
already provide default configs but it is still difficult to express
what needs to be configured for the different environments. On the other 
hand I think that these configs have a different lifecycle than the 
application code. So I think it needs to be handled separately from 
features.


I have scoped such a scenario a long time ago here:
http://liquid-reality.de/display/liquid/Software+Development+and+Deployment

This is just an overview of the problem though and does not provide an 
actual solution.


We are also toying with the idea of a “user operator” (kind of a 
support person, but who interfaces with the OSGi system) or something 
like that, meaning somebody who can install new users, help users fix 
problems during runtime, and so on.


The more expertise these operators require (such as OSGi / 
bundle-level knowledge) the costlier the system becomes.


To get back to the point… enRoute/bndtools seems to promote the idea 
of an “application bundle”, which pulls in all the required 
dependencies. If this bundle already provides everything I need to get 
a “feature” (in the general sense) up and running, then why all the 
extra cruft around it? All I need to do is detect this “application 
bundle(s)” in my OBR, and I can just pull in the other requirements. No?
Not sure about the application bundle. What I saw is that bndtools uses 
the bndrun file to define the requirements for the resolver.
I agree that in the application case features are not absolutely 
required. In fact I talked to Peter Kriens at eclipsecon about it and he 
is not yet convinced that features are needed.
I have also done some tests in bndtools and was able to get cxf as well 
as jpa + hibernate running just with a obr repo and a bndrun file. The 
list of bundles / requirements I needed to define was not that big.


On the other hand features can define things that you might overlook 
when just using a bndrun file. So for example CXF would like to replace 
certain jdk built in specs and impls for security or performance 
reasons. These things are more difficult to express in the form of a 
bndrun file.


Christian

Re: Bndtools & Karaf : the right way

> Do you have pointers about those "application bundles” ?

How about this?

  
https://github.com/osgi/osgi.enroute.examples/blob/master/osgi.enroute.examples.cm.application/src/osgi/enroute/examples/cm/application/CmApplication.java
 


There may be better examples out there, but I think this gives the idea…


Cheers,
=David

Re: Bndtools & Karaf : the right way


Hi David,

it's very close to the karaf boot purpose (using annotation to create 
the application bootstrapping) ;)


Regards
JB

On 11/26/2015 11:30 AM, David Leangen wrote:

Do you have pointers about those "application bundles” ?


How about this?

https://github.com/osgi/osgi.enroute.examples/blob/master/osgi.enroute.examples.cm.application/src/osgi/enroute/examples/cm/application/CmApplication.java

There may be better examples out there, but I think this gives the idea…


Cheers,
=David




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

Re: Bndtools & Karaf : the right way


>> I can envision, for instance, configuration parameters on 3 levels:
>> 
>> 1) default parameters (probably provided in the code)
>> 2) default parameters for a specific installation / runtime
>> 3) maintenance or operational parameters
> 
> I have scoped such a scenario a long time ago here:
> http://liquid-reality.de/display/liquid/Software+Development+and+Deployment 
> 

Yes, I think this is quite similar. :-)


> Not sure about the application bundle. What I saw is that bndtools uses the 
> bndrun file to define the requirements for the resolver.

From the enRoute website:

  http://enroute.osgi.org/tutorial_base/700-deploy.html 


   A bndrun file [...] allows us to specify a runtime for our framework.

Also, closer to the end:

How Does it Work?
bndrun files define the requirements on a desired runtime. When the Resolve 
button is hit, the bnd resolver looks at the initial requirements and will try 
to find resources in the repositories that together match those requirements 
and the requirements from the introduced resources. The resulting set of 
bundles defines a runtime, these bundles are set in the -runbundles instruction.
A runtime environment can then be executed to verify it, potentially resulting 
in some modifications. If the result is ok, then the export function of bnd is 
used.
The bnd export goes through a plugin; this is the same plugin that manages the 
launching. In this case this is the default aQute.launch plugin. The plugin 
takes the runtime environment and creates a JAR that contains all the 
dependencies, including itself and any properties; creating a JAR that is 
completely self contained.

This corresponds to how I use it. The dependencies are defined in the 
application bundle via annotations, and a default configuration is also 
provided in the bundle. All the bndrun file is is an index of the results of 
what happens when you hit “resolve”.


My understanding is that Karaf IS the runtime, and can do the resolution at 
runtime, so there is really no need for a bndrun file.

Where I can see the plugin being useful, though, is if you want to run Karaf 
directly in the Eclipse container. Otherwise, the runtime descriptor could just 
as easily be generated at runtime, provided of course there is enough 
information available to generate it.

> On the other hand features can define things that you might overlook when 
> just using a bndrun file. So for example CXF would like to replace certain 
> jdk built in specs and impls for security or performance reasons. These 
> things are more difficult to express in the form of a bndrun file.

Yes, agree. For this, some extension mechanism would be required in addition to 
the OBR + requirements. As you mentioned previously, eventually if this were 
part of the OBR spec, it would be ideal.

Cheers,
=David

Re: Bndtools & Karaf : the right way


On 26.11.2015 11:40, David Leangen wrote:

This corresponds to how I use it. The dependencies are defined in the
application bundle via annotations, and a default configuration is
also provided in the bundle. All the bndrun file is is an index of the
results of what happens when you hit “resolve”.
These annotations will create the requirements of the bundle Manifest. 
It is not guaranteed though that this describes all of your application.



My understanding is that Karaf IS the runtime, and can do the
resolution at runtime, so there is really no need for a bndrun file.
It depends on the use case who does the resolve. In the application mode 
bndtools would do the resolving and you would not use the karaf resolver.

In the server use case you would let karaf do the resolve at runtime.

In both cases a bndrun or similar is necessary. The bndrun file does not 
only contain the runbundles which is the already resolved list. It also 
contains the requirements. The minimum thing it would contain in your 
case is
a pointer to your application bundle. In many cases it will contain a 
list of requirements for bundles and maybe other requirements.


This part of the bndrun file is the input for the resolver. This is 
always needed.



On the other hand features can define things that you might overlook
when just using a bndrun file. So for example CXF would like to
replace certain jdk built in specs and impls for security or
performance reasons. These things are more difficult to express in
the form of a bndrun file.


Yes, agree. For this, some extension mechanism would be required in
addition to the OBR + requirements. As you mentioned previously,
eventually if this were part of the OBR spec, it would be ideal.
It is the purpose of a feature file or a bndrun file. The obr index is 
just the pool of bundles/resources to pick from. You need to give the 
resolver the initial hooks to pull the needed bundles out of this pool.


Christian

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

Open Source Architect
http://www.talend.com

Re: Bndtools & Karaf : the right way


Hi Christian,

> In both cases a bndrun or similar is necessary. The bndrun file does not only 
> contain the runbundles which is the already resolved list. It also contains 
> the requirements. The minimum thing it would contain in your case is a 
> pointer to your application bundle. In many cases it will contain a list of 
> requirements for bundles and maybe other requirements.

Ok, so taking a different tack…

> The obr index is just the pool of bundles/resources to pick from.

Without reviewing the spec, I’ll take your word for it. :-)

> This part of the bndrun file is the input for the resolver. This is always 
> needed. […] It is the purpose of a feature file or a bndrun file. [...] You 
> need to give the resolver the initial hooks to pull the needed bundles out of 
> this pool.

What I understand from what you write is that the bndrun/feature file (call it 
a “runtime descriptor”?) is also nothing but a list of requirements and 
capabilities. If so, it seems to be essentially the same thing as an obr index: 
a list of resources with requirements and capabilities. The only difference I 
can see is that the obr index is for storing stuff and is ignorant of the 
runtime, while the the runtime descriptor only cares about what is required 
during a runtime, and doesn’t care if it contains all the stored resources or 
not. The contents otherwise seem very similar, if not identical.

Sounds like two different views on the same thing, maybe.

Or perhaps the features.xml file is itself nothing but a resource (having 
requirements and capabilities) that could be expressed in an obr index.


Also, I am still a bit stuck on the fact that the developers are the ones 
expected to create the runtime descriptor. I can understand if they want to 
immediately run something in a local test environment, but otherwise it seems 
to couple the devs to the deployment/runtime. Am I missing something, or is 
this related to the page of the yet-to-be-developers scenario you showed in 
your previous post (reposted below)?

> I have scoped such a scenario a long time ago here:
> http://liquid-reality.de/display/liquid/Software+Development+and+Deployment 
> 

Cheers,
=David

Re: Bndtools & Karaf : the right way

2015-11-26 11:04 GMT+01:00 Christian Schneider :

> Hi Guillaume,
>
> as far as I know a bnd application is defined using a bndrun file and one
> or more repositories.
> So basically you define requirements and a bundle repository to resolve
> against. Bndtools then creates the list of bundles interactively in the
> eclipse bndtools UI. At build time you then already have the final list of
> bundles.
> I think this could be enhanced to also allow the resolve step to take
> place at build time but as long as bndtools is doing the resolving we
> probably would not notice the difference anyway on the karaf side.
>
> For the features to work in bndtools as well as in karaf we would need to
> define a common format to define a requirement that represents a feature as
> well as to represent the content of a feature. Ideally I think this should
> then be standardized at some point
> so it can be used in a wider range of environments. Ultimately it would be
> great to even find a common way together with the eclipse pde community.
>

The requirement for a feature is already formalized in karaf:

osgi.identity;osgi.identity=feature-name;type=karaf.feature;version="version-range"



> Christian
>
>
> Am 26.11.2015 um 10:16 schrieb Guillaume Nodet:
>
> Just a few points I want to mention in this discussion.
>
> The karaf deployer uses the OSGi resolver.  Features are modelled into
> OSGi resources, the exact same way as bundles, so they can easily be
> written with the standard xml description.  It's just a matter of writing
> back resource generated from the feature as an xml (and the code already
> exists).
> See
>
> https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/resolver/FeatureResource.java#L48-L71
>
> I agree the xml repository would be better placed as a top level element,
> along feature repositories.
>
> As for deployment, I haven't seen how "bnd applications" are modelled, but
> the karaf deployer can be given abstract requirements.  When one installs a
> feature, it's simply translated into a new requirement that point to this
> feature.
>
> https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/resolver/ResourceUtils.java#L169-L180
>
> Guillaume
>
>
>
> 2015-11-26 9:52 GMT+01:00 Christian Schneider :
>
>> On 26.11.2015 08:52, David Leangen wrote:
>>
>>
>>
>> Then perhaps all we need to do is allow a Feature to include an OBR repo
>> as an option.
>>
>> Bundles in the feature could provide a capability (for example in the
>> “namespace=karaf.feature”) to flag it as a bundle to be included in the
>> feature.
>>
>> http://karaf.apache.org/xmlns/features/v1.3.0>
>> http://karaf.apache.org/xmlns/features/v1.3.0; name=“my-feature-set">
>> 
>> *
>> http://host.com/path/to/repo/index.xml
>> *
>> 
>> 
>>
>> I think it would make more sense to have the obr element on top level of
>> the features xml as I think the obr repository would be that basis of all
>> the features in the file.
>>
>> I have written down some ideas here some time ago:
>>
>> http://liquid-reality.de/display/liquid/Design+repository+based+features+for+Apache+Karaf
>>
>> Ideally we should work together on a complete design in an apache wiki so
>> all can help.
>>
>>
>> And in the OBR:
>>
>> http://www.osgi.org/xmlns/repository/v1.0.0>
>> http://www.osgi.org/xmlns/repository/v1.0.0; increment=“1" name="Release"
>> >
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>
>> ...
>> **
>> *> " value=“name.of.feature/1.0.0"/>*
>> **
>> **
>> *  *
>> **
>> **
>>
>> 
>> 
>> 
>>
>> ...
>>
>> 
>> 
>>
>>
>> I agree we would need to also bring the features into the OBR at some
>> point. Karaf already uses a special capability to describe features
>> internally to feed the resolver. We should be able to extend and
>> standardize this.
>>
>> As karaf features are proprietary we might be able to use subsystem
>> descriptors (in their feature mode). In fact they look a lot like bndrun
>> files already. So maybe the subsystem spec could be enhanced to cover that
>> case.
>>
>> (Not sure if the attributes should be there or not, just added them in as
>> an afterthought.)
>>
>> In any case, all the bundle information etc. is already there, so it
>> seems unnecessary to have to duplicate it in in a features.xml file.
>>
>> I think it would not be a good idea to use an OBR repository to describe
>> a feature. An OBR repository is more like the target platform in eclipse
>> PDE. It defines which bundles are available and what they provide and need.
>> The feature should then define the requirements to help the resolver
>> decide which bundles from the repository to combine to make the feature
>> resolvable. This is then very similar to a bndrun file.
>>
>> The main question here is how to define

Re: Bndtools & Karaf : the right way


On 26.11.2015 12:54, David Leangen wrote:


Hi Christian,



This part of the bndrun file is the input for the resolver. This is 
always needed. […] It is the purpose of a feature file or a bndrun 
file. [...] You need to give the resolver the initial hooks to pull 
the needed bundles out of this pool.


What I understand from what you write is that the bndrun/feature file 
(call it a “runtime descriptor”?) is also nothing but a list of 
requirements and capabilities. If so, it seems to be essentially the 
same thing as an obr index: a list of resources with requirements and 
capabilities. The only difference I can see is that the obr index is 
for storing stuff and is ignorant of the runtime, while the the 
runtime descriptor only cares about what is required during a runtime, 
and doesn’t care if it contains all the stored resources or not. The 
contents otherwise seem very similar, if not identical.


Sounds like two different views on the same thing, maybe.
They are kind of similar but you could argue the same for bundles and 
the obr index. The bundle contains the requirement and capability 
headers as well as the index. Still you need the bundles as the index is 
created out of the bundle meta data. So in some way you could consider 
the index to be just a cache for the meta data. It could be replaced by 
just a list of resources as the resolver could also look into each 
bundle / feature / bndrun file individually.


Or perhaps the features.xml file is itself nothing but a resource 
(having requirements and capabilities) that could be expressed in an 
obr index.
The feature/bndrun file is indeed a resource in the obr repository 
sense. You still need it though as the index is normally created out of 
something (as it is a kind of cache).



Also, I am still a bit stuck on the fact that the developers are the 
ones expected to create the runtime descriptor. I can understand if 
they want to immediately run something in a local test environment, 
but otherwise it seems to couple the devs to the deployment/runtime. 
Am I missing something, or is this related to the page of the 
yet-to-be-developers scenario you showed in your previous post 
(reposted below)?
Theoretically you could have a split there that developers only write 
the code of bundles and do not care about the deployment at all. In 
reality you want to create automated build/test pipelines that maybe 
reach even into

production.

As you correctly stated developers need to at the very least test their 
code locally. So they need to be involved at least in that part of the 
pipeline. In fact developers are normally also responsible for the 
integration tests that run locally as well as in a dev or test 
environments. On the other hand you could have a deployer role that is 
responsible for all of this. So yes you can say that the developer is 
not responsible for the features.
As you typically want to build kind of devops teams today in the end the 
development team is most times responsible for development + deployment 
sometimes until dev, test sometimes even to production.


What I see in practice is that the real admins (that are not part of the 
dev team) often are just responsible for the production servers. As the 
deployment must already be present for previous steps in the pipeline it 
typically does not make sense to let them define the deployment on their 
own.


Christian


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

Open Source Architect
http://www.talend.com

Re: Bndtools & Karaf : the right way


Hi Christian,

Thank you very much for this discussion. It is very interesting (and 
educational) since it is relevant to my current top priority: getting our 
development—> deployment pipeline up and running quickly.

Getting back to more immediate practical matters…

Given that there is not currently a bnd plugin to create a features file, and 
since I do not want to head in a solitary direction, what do you recommend I do 
to automate the generation / installation of my features?

What I have:
 * OBR repositories “deployed” by the devs, which are handed over to the 
deployer
 * A Karaf command for the deployer to browse the available OBR repos

What I need:
 * A means to actually install and start the bundles


I don’t mind doing this against the Features service in runtime, since I am 
building a “deployment” service anyway, to be used by the deployer.

Any thoughts to help me get up and running quickly would be very welcome. :-)



Cheers,
=David


On Nov 26, 2015, at 10:20 PM, Christian Schneider  
wrote:

> On 26.11.2015 12:54, David Leangen wrote:
>> 
>> Hi Christian,
>> 
>> 
>> 
>>> This part of the bndrun file is the input for the resolver. This is always 
>>> needed. […] It is the purpose of a feature file or a bndrun file. [...] You 
>>> need to give the resolver the initial hooks to pull the needed bundles out 
>>> of this pool.
>> 
>> What I understand from what you write is that the bndrun/feature file (call 
>> it a “runtime descriptor”?) is also nothing but a list of requirements and 
>> capabilities. If so, it seems to be essentially the same thing as an obr 
>> index: a list of resources with requirements and capabilities. The only 
>> difference I can see is that the obr index is for storing stuff and is 
>> ignorant of the runtime, while the the runtime descriptor only cares about 
>> what is required during a runtime, and doesn’t care if it contains all the 
>> stored resources or not. The contents otherwise seem very similar, if not 
>> identical.
>> 
>> Sounds like two different views on the same thing, maybe.
> They are kind of similar but you could argue the same for bundles and the obr 
> index. The bundle contains the requirement and capability headers as well as 
> the index. Still you need the bundles as the index is created out of the 
> bundle meta data. So in some way you could consider the index to be just a 
> cache for the meta data. It could be replaced by just a list of resources as 
> the resolver could also look into each bundle / feature / bndrun file 
> individually. 
>> 
>> Or perhaps the features.xml file is itself nothing but a resource (having 
>> requirements and capabilities) that could be expressed in an obr index.
> The feature/bndrun file is indeed a resource in the obr repository sense. You 
> still need it though as the index is normally created out of something (as it 
> is a kind of cache).
>> 
>> 
>> Also, I am still a bit stuck on the fact that the developers are the ones 
>> expected to create the runtime descriptor. I can understand if they want to 
>> immediately run something in a local test environment, but otherwise it 
>> seems to couple the devs to the deployment/runtime. Am I missing something, 
>> or is this related to the page of the yet-to-be-developers scenario you 
>> showed in your previous post (reposted below)?
> Theoretically you could have a split there that developers only write the 
> code of bundles and do not care about the deployment at all. In reality you 
> want to create automated build/test pipelines that maybe reach even into 
> production. 
> 
> As you correctly stated developers need to at the very least test their code 
> locally. So they need to be involved at least in that part of the pipeline. 
> In fact developers are normally also responsible for the integration tests 
> that run locally as well as in a dev or test environments. On the other hand 
> you could have a deployer role that is responsible for all of this. So yes 
> you can say that the developer is not responsible for the features.
> As you typically want to build kind of devops teams today in the end the 
> development team is most times responsible for development + deployment 
> sometimes until dev, test sometimes even to production.
> 
> What I see in practice is that the real admins (that are not part of the dev 
> team) often are just responsible for the production servers. As the 
> deployment must already be present for previous steps in the pipeline it 
> typically does not make sense to let them define the deployment on their own.
> 
> Christian
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com

Re: Bndtools & Karaf : the right way