You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by David Leangen <ap...@leangen.net> on 2017/06/14 05:49:57 UTC
Karaf Feature vs. OBR
Hi!
I am trying to wrap my head around the differences between an OBR and a Karaf Feature. The concepts seem to be overlapping.
An OBR has an index of the contained bundles, as well as meta information, which includes requirements and capabilities. An OBR is therefore very useful for resolving bundles, and partitioning bundles into some kind of category. It can also be versioned, and can contained different versions of bundles. An OBR could potentially be used to keep snapshots of system releases. I believe that this is somewhat how Apache ACE works. (A Distribution can be rolled back by simply referring to a different OBR and allowing the system to re-resolve.) The actual bundles need to be stored somewhere. The OBR index needs to provide links to that storage.
A Karaf Feature is basically an index of bundles (and configurations), too. I think that it can also be versioned, and can contain different versions of bundles. Like an OBR, it is very useful for partitioning bundles into some kind of category, so the groups of bundles can be manipulated as a single unit. Just like an OBR, the Karaf Feature also needs to provide a link to the bundles. AFAIU, resolution is done somehow in Karaf, based on the bundles available via the Features, so in the end the entire mechanism seems almost identical to what the OBR is doing.
So many similarities!
I understand that a Feature can include configurations, which is nice, but why have a competing non-official standard against an official standard? If configurations is the only problem, then why not build it on top of OBRs, rather than creating something completely new and different and competing?
Is it to try to force lock-in to Karaf? Or am I completely missing something?
Thanks for explaining! :-)
Cheers,
=David
Re: Karaf Feature vs. OBR
Posted by David Leangen <ap...@leangen.net>.
I just did a Google search for apache cave nexus to see if anybody provided a comparison, and this is what I found:
https://books.google.co.jp/books?id=JC3QD47hu24C&pg=PA280&lpg=PA280&dq=apache+cave+vs+nexus&source=bl&ots=zyJRNO8SlK&sig=qlaz61q4d7s8PbrYFEZnnQP-tlc&hl=en&sa=X&ved=0ahUKEwjphJXJjb7UAhUES7wKHVk8BXgQ6AEILDAB#v=onepage&q&f=false <https://books.google.co.jp/books?id=JC3QD47hu24C&pg=PA280&lpg=PA280&dq=apache+cave+vs+nexus&source=bl&ots=zyJRNO8SlK&sig=qlaz61q4d7s8PbrYFEZnnQP-tlc&hl=en&sa=X&ved=0ahUKEwjphJXJjb7UAhUES7wKHVk8BXgQ6AEILDAB#v=onepage&q&f=false>
An Apache Life-Way
… the first moccasin game was played there in a hint of such a nexus. “At the bottom of this hole, a cave…
:-)
=David
> On Jun 15, 2017, at 4:47 AM, David Leangen <ap...@leangen.net> wrote:
>
>
> Thank you JB and Christian,
>
> I think that about answers my question. Right now I don’t have time to actually invest in doing anything about it, but I was just curious. :-)
>
>
> Cheers,
> =David
>
>
>> On Jun 15, 2017, at 1:49 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>
>> And anyway, Karaf Features can leverage OBR (directly or via Cave).
>>
>> Karaf can load OBR repos in org.apache.karaf.features.cfg and use it directly.
>>
>> Regards
>> JB
>>
>> On 06/14/2017 06:46 PM, Christian Schneider wrote:
>>> Hi David,
>>> I think the reason is more that features in karaf used to work a lot simpler in the start. They were simply a list of bundles to install. Over time features got more and more abilities.
>>> So it is less to lock in people and more simply a history matter.
>>> Since karaf 4 features use the felix resolver. You can imagine a feature as a mix of obr and requirements for the resolver.
>>> If a bundle in a feature is marked as dependency=true then it behaves in the same way as a bundle listed in an OBR if the feature is installed. It is simply there to be selected if necessary. If dependency=false (the default) then the bundle is also a requirement for the resolver if the feature is to be installed.
>>> I agree with you that it would be great to move to a more general way that then also works in different environments.
>>> Some time ago I wrote down some ideas for a feature replacement that is less karaf specific.
>>> http://liquid-reality.de/display/liquid/Design+repository+based+features+for+Apache+Karaf
>>> The main things features provide:
>>> - List of bundles to choose from
>>> - List of bundles to install (requirements)
>>> - Configs to install
>>> - Conditionally install additional bundles if other features are present
>>> The first three things can already be done without features:
>>> - An OBR index can supply the list of bundles to choose from ( I already started to provide OBR repos in some projects like Aries RSA)
>>> - We could use a list of top level bundles as initial requirements
>>> - A bundle can require other bundles using Require-Bundle headers. This could allow feature like bundles that list other top level bundles
>>> - Configurations can be provided inside of bundles using the Configurer spec and impl from enroute
>>> For conditional bundles there is no replacement outside of features.
>>> So we could develop a replacement of features that works in all OSGi environments. It is just matter of knowledge and effort to implement this.
>>> You can see in the CXF-DOSGi SOAP sample what can already be done with OBR and a resolver:
>>> https://github.com/apache/cxf-dosgi/blob/master/samples/soap/soap.bndrun#L1-L41
>>> The runbundles are automatically determined by the resolver.
>>> As you can see it is already possible but still quite a bit more effort than with karaf features at the moment.
>>> Christian
>>> 2017-06-14 7:49 GMT+02:00 David Leangen <apache@leangen.net <ma...@leangen.net>>:
>>> Hi!
>>> I am trying to wrap my head around the differences between an OBR and a
>>> Karaf Feature. The concepts seem to be overlapping.
>>> An OBR has an index of the contained bundles, as well as meta information,
>>> which includes requirements and capabilities. An OBR is therefore very
>>> useful for resolving bundles, and partitioning bundles into some kind of
>>> category. It can also be versioned, and can contained different versions of
>>> bundles. An OBR could potentially be used to keep snapshots of system
>>> releases. I believe that this is somewhat how Apache ACE works. (A
>>> Distribution can be rolled back by simply referring to a different OBR and
>>> allowing the system to re-resolve.) The actual bundles need to be stored
>>> somewhere. The OBR index needs to provide links to that storage.
>>> A Karaf Feature is basically an index of bundles (and configurations), too.
>>> I think that it can also be versioned, and can contain different versions of
>>> bundles. Like an OBR, it is very useful for partitioning bundles into some
>>> kind of category, so the groups of bundles can be manipulated as a single
>>> unit. Just like an OBR, the Karaf Feature also needs to provide a link to
>>> the bundles. AFAIU, resolution is done somehow in Karaf, based on the
>>> bundles available via the Features, so in the end the entire mechanism seems
>>> almost identical to what the OBR is doing.
>>> So many similarities!
>>> I understand that a Feature can include configurations, which is nice, but
>>> why have a competing non-official standard against an official standard? If
>>> configurations is the only problem, then why not build it on top of OBRs,
>>> rather than creating something completely new and different and competing?
>>> Is it to try to force lock-in to Karaf? Or am I completely missing something?
>>> Thanks for explaining! :-)
>>> Cheers,
>>> =David
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>>> Open Source Architect
>>> http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
Re: Karaf Feature vs. OBR
Posted by David Leangen <ap...@leangen.net>.
Thank you JB and Christian,
I think that about answers my question. Right now I don’t have time to actually invest in doing anything about it, but I was just curious. :-)
Cheers,
=David
> On Jun 15, 2017, at 1:49 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> And anyway, Karaf Features can leverage OBR (directly or via Cave).
>
> Karaf can load OBR repos in org.apache.karaf.features.cfg and use it directly.
>
> Regards
> JB
>
> On 06/14/2017 06:46 PM, Christian Schneider wrote:
>> Hi David,
>> I think the reason is more that features in karaf used to work a lot simpler in the start. They were simply a list of bundles to install. Over time features got more and more abilities.
>> So it is less to lock in people and more simply a history matter.
>> Since karaf 4 features use the felix resolver. You can imagine a feature as a mix of obr and requirements for the resolver.
>> If a bundle in a feature is marked as dependency=true then it behaves in the same way as a bundle listed in an OBR if the feature is installed. It is simply there to be selected if necessary. If dependency=false (the default) then the bundle is also a requirement for the resolver if the feature is to be installed.
>> I agree with you that it would be great to move to a more general way that then also works in different environments.
>> Some time ago I wrote down some ideas for a feature replacement that is less karaf specific.
>> http://liquid-reality.de/display/liquid/Design+repository+based+features+for+Apache+Karaf
>> The main things features provide:
>> - List of bundles to choose from
>> - List of bundles to install (requirements)
>> - Configs to install
>> - Conditionally install additional bundles if other features are present
>> The first three things can already be done without features:
>> - An OBR index can supply the list of bundles to choose from ( I already started to provide OBR repos in some projects like Aries RSA)
>> - We could use a list of top level bundles as initial requirements
>> - A bundle can require other bundles using Require-Bundle headers. This could allow feature like bundles that list other top level bundles
>> - Configurations can be provided inside of bundles using the Configurer spec and impl from enroute
>> For conditional bundles there is no replacement outside of features.
>> So we could develop a replacement of features that works in all OSGi environments. It is just matter of knowledge and effort to implement this.
>> You can see in the CXF-DOSGi SOAP sample what can already be done with OBR and a resolver:
>> https://github.com/apache/cxf-dosgi/blob/master/samples/soap/soap.bndrun#L1-L41
>> The runbundles are automatically determined by the resolver.
>> As you can see it is already possible but still quite a bit more effort than with karaf features at the moment.
>> Christian
>> 2017-06-14 7:49 GMT+02:00 David Leangen <apache@leangen.net <ma...@leangen.net>>:
>> Hi!
>> I am trying to wrap my head around the differences between an OBR and a
>> Karaf Feature. The concepts seem to be overlapping.
>> An OBR has an index of the contained bundles, as well as meta information,
>> which includes requirements and capabilities. An OBR is therefore very
>> useful for resolving bundles, and partitioning bundles into some kind of
>> category. It can also be versioned, and can contained different versions of
>> bundles. An OBR could potentially be used to keep snapshots of system
>> releases. I believe that this is somewhat how Apache ACE works. (A
>> Distribution can be rolled back by simply referring to a different OBR and
>> allowing the system to re-resolve.) The actual bundles need to be stored
>> somewhere. The OBR index needs to provide links to that storage.
>> A Karaf Feature is basically an index of bundles (and configurations), too.
>> I think that it can also be versioned, and can contain different versions of
>> bundles. Like an OBR, it is very useful for partitioning bundles into some
>> kind of category, so the groups of bundles can be manipulated as a single
>> unit. Just like an OBR, the Karaf Feature also needs to provide a link to
>> the bundles. AFAIU, resolution is done somehow in Karaf, based on the
>> bundles available via the Features, so in the end the entire mechanism seems
>> almost identical to what the OBR is doing.
>> So many similarities!
>> I understand that a Feature can include configurations, which is nice, but
>> why have a competing non-official standard against an official standard? If
>> configurations is the only problem, then why not build it on top of OBRs,
>> rather than creating something completely new and different and competing?
>> Is it to try to force lock-in to Karaf? Or am I completely missing something?
>> Thanks for explaining! :-)
>> Cheers,
>> =David
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>> Open Source Architect
>> http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Karaf Feature vs. OBR
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
No, the OSGi Repository spec.
Regards
JB
On 06/14/2017 08:43 PM, Leschke, Scott wrote:
> When we say "OBR" are we referring to the OSGi Subsystem spec?
>
> Scott
>
> -----Original Message-----
> From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
> Sent: Wednesday, June 14, 2017 11:49 AM
> To: user@karaf.apache.org
> Subject: Re: Karaf Feature vs. OBR
>
> And anyway, Karaf Features can leverage OBR (directly or via Cave).
>
> Karaf can load OBR repos in org.apache.karaf.features.cfg and use it directly.
>
> Regards
> JB
>
> On 06/14/2017 06:46 PM, Christian Schneider wrote:
>> Hi David,
>>
>> I think the reason is more that features in karaf used to work a lot
>> simpler in the start. They were simply a list of bundles to install.
>> Over time features got more and more abilities.
>> So it is less to lock in people and more simply a history matter.
>>
>> Since karaf 4 features use the felix resolver. You can imagine a
>> feature as a mix of obr and requirements for the resolver.
>> If a bundle in a feature is marked as dependency=true then it behaves
>> in the same way as a bundle listed in an OBR if the feature is
>> installed. It is simply there to be selected if necessary. If
>> dependency=false (the default) then the bundle is also a requirement for the resolver if the feature is to be installed.
>>
>> I agree with you that it would be great to move to a more general way
>> that then also works in different environments.
>> Some time ago I wrote down some ideas for a feature replacement that
>> is less karaf specific.
>> http://liquid-reality.de/display/liquid/Design+repository+based+featur
>> es+for+Apache+Karaf
>>
>> The main things features provide:
>>
>> - List of bundles to choose from
>> - List of bundles to install (requirements)
>> - Configs to install
>> - Conditionally install additional bundles if other features are
>> present
>>
>> The first three things can already be done without features:
>> - An OBR index can supply the list of bundles to choose from ( I
>> already started to provide OBR repos in some projects like Aries RSA)
>> - We could use a list of top level bundles as initial requirements
>> - A bundle can require other bundles using Require-Bundle headers.
>> This could allow feature like bundles that list other top level
>> bundles
>> - Configurations can be provided inside of bundles using the
>> Configurer spec and impl from enroute
>>
>> For conditional bundles there is no replacement outside of features.
>>
>> So we could develop a replacement of features that works in all OSGi
>> environments. It is just matter of knowledge and effort to implement this.
>>
>> You can see in the CXF-DOSGi SOAP sample what can already be done
>> with OBR and a resolver:
>> https://github.com/apache/cxf-dosgi/blob/master/samples/soap/soap.bndr
>> un#L1-L41 The runbundles are automatically determined by the resolver.
>> As you can see it is already possible but still quite a bit more
>> effort than with karaf features at the moment.
>>
>> Christian
>>
>>
>>
>> 2017-06-14 7:49 GMT+02:00 David Leangen <apache@leangen.net
>> <ma...@leangen.net>>:
>>
>>
>> Hi!
>>
>> I am trying to wrap my head around the differences between an OBR and a
>> Karaf Feature. The concepts seem to be overlapping.
>>
>> An OBR has an index of the contained bundles, as well as meta information,
>> which includes requirements and capabilities. An OBR is therefore very
>> useful for resolving bundles, and partitioning bundles into some kind of
>> category. It can also be versioned, and can contained different versions of
>> bundles. An OBR could potentially be used to keep snapshots of system
>> releases. I believe that this is somewhat how Apache ACE works. (A
>> Distribution can be rolled back by simply referring to a different OBR and
>> allowing the system to re-resolve.) The actual bundles need to be stored
>> somewhere. The OBR index needs to provide links to that storage.
>>
>> A Karaf Feature is basically an index of bundles (and configurations), too.
>> I think that it can also be versioned, and can contain different versions of
>> bundles. Like an OBR, it is very useful for partitioning bundles into some
>> kind of category, so the groups of bundles can be manipulated as a single
>> unit. Just like an OBR, the Karaf Feature also needs to provide a link to
>> the bundles. AFAIU, resolution is done somehow in Karaf, based on the
>> bundles available via the Features, so in the end the entire mechanism seems
>> almost identical to what the OBR is doing.
>>
>>
>> So many similarities!
>>
>>
>> I understand that a Feature can include configurations, which is nice, but
>> why have a competing non-official standard against an official standard? If
>> configurations is the only problem, then why not build it on top of OBRs,
>> rather than creating something completely new and different and competing?
>>
>> Is it to try to force lock-in to Karaf? Or am I completely missing something?
>>
>>
>> Thanks for explaining! :-)
>>
>>
>> Cheers,
>> =David
>>
>>
>>
>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7
>> e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>>
>> Open Source Architect
>> http://www.talend.com
>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7
>> e46&URL=http%3a%2f%2fwww.talend.com>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
RE: Karaf Feature vs. OBR
Posted by "Leschke, Scott" <SL...@medline.com>.
When we say "OBR" are we referring to the OSGi Subsystem spec?
Scott
-----Original Message-----
From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
Sent: Wednesday, June 14, 2017 11:49 AM
To: user@karaf.apache.org
Subject: Re: Karaf Feature vs. OBR
And anyway, Karaf Features can leverage OBR (directly or via Cave).
Karaf can load OBR repos in org.apache.karaf.features.cfg and use it directly.
Regards
JB
On 06/14/2017 06:46 PM, Christian Schneider wrote:
> Hi David,
>
> I think the reason is more that features in karaf used to work a lot
> simpler in the start. They were simply a list of bundles to install.
> Over time features got more and more abilities.
> So it is less to lock in people and more simply a history matter.
>
> Since karaf 4 features use the felix resolver. You can imagine a
> feature as a mix of obr and requirements for the resolver.
> If a bundle in a feature is marked as dependency=true then it behaves
> in the same way as a bundle listed in an OBR if the feature is
> installed. It is simply there to be selected if necessary. If
> dependency=false (the default) then the bundle is also a requirement for the resolver if the feature is to be installed.
>
> I agree with you that it would be great to move to a more general way
> that then also works in different environments.
> Some time ago I wrote down some ideas for a feature replacement that
> is less karaf specific.
> http://liquid-reality.de/display/liquid/Design+repository+based+featur
> es+for+Apache+Karaf
>
> The main things features provide:
>
> - List of bundles to choose from
> - List of bundles to install (requirements)
> - Configs to install
> - Conditionally install additional bundles if other features are
> present
>
> The first three things can already be done without features:
> - An OBR index can supply the list of bundles to choose from ( I
> already started to provide OBR repos in some projects like Aries RSA)
> - We could use a list of top level bundles as initial requirements
> - A bundle can require other bundles using Require-Bundle headers.
> This could allow feature like bundles that list other top level
> bundles
> - Configurations can be provided inside of bundles using the
> Configurer spec and impl from enroute
>
> For conditional bundles there is no replacement outside of features.
>
> So we could develop a replacement of features that works in all OSGi
> environments. It is just matter of knowledge and effort to implement this.
>
> You can see in the CXF-DOSGi SOAP sample what can already be done
> with OBR and a resolver:
> https://github.com/apache/cxf-dosgi/blob/master/samples/soap/soap.bndr
> un#L1-L41 The runbundles are automatically determined by the resolver.
> As you can see it is already possible but still quite a bit more
> effort than with karaf features at the moment.
>
> Christian
>
>
>
> 2017-06-14 7:49 GMT+02:00 David Leangen <apache@leangen.net
> <ma...@leangen.net>>:
>
>
> Hi!
>
> I am trying to wrap my head around the differences between an OBR and a
> Karaf Feature. The concepts seem to be overlapping.
>
> An OBR has an index of the contained bundles, as well as meta information,
> which includes requirements and capabilities. An OBR is therefore very
> useful for resolving bundles, and partitioning bundles into some kind of
> category. It can also be versioned, and can contained different versions of
> bundles. An OBR could potentially be used to keep snapshots of system
> releases. I believe that this is somewhat how Apache ACE works. (A
> Distribution can be rolled back by simply referring to a different OBR and
> allowing the system to re-resolve.) The actual bundles need to be stored
> somewhere. The OBR index needs to provide links to that storage.
>
> A Karaf Feature is basically an index of bundles (and configurations), too.
> I think that it can also be versioned, and can contain different versions of
> bundles. Like an OBR, it is very useful for partitioning bundles into some
> kind of category, so the groups of bundles can be manipulated as a single
> unit. Just like an OBR, the Karaf Feature also needs to provide a link to
> the bundles. AFAIU, resolution is done somehow in Karaf, based on the
> bundles available via the Features, so in the end the entire mechanism seems
> almost identical to what the OBR is doing.
>
>
> So many similarities!
>
>
> I understand that a Feature can include configurations, which is nice, but
> why have a competing non-official standard against an official standard? If
> configurations is the only problem, then why not build it on top of OBRs,
> rather than creating something completely new and different and competing?
>
> Is it to try to force lock-in to Karaf? Or am I completely missing something?
>
>
> Thanks for explaining! :-)
>
>
> Cheers,
> =David
>
>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7
> e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7
> e46&URL=http%3a%2f%2fwww.talend.com>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf Feature vs. OBR
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
And anyway, Karaf Features can leverage OBR (directly or via Cave).
Karaf can load OBR repos in org.apache.karaf.features.cfg and use it directly.
Regards
JB
On 06/14/2017 06:46 PM, Christian Schneider wrote:
> Hi David,
>
> I think the reason is more that features in karaf used to work a lot simpler in
> the start. They were simply a list of bundles to install. Over time features got
> more and more abilities.
> So it is less to lock in people and more simply a history matter.
>
> Since karaf 4 features use the felix resolver. You can imagine a feature as a
> mix of obr and requirements for the resolver.
> If a bundle in a feature is marked as dependency=true then it behaves in the
> same way as a bundle listed in an OBR if the feature is installed. It is simply
> there to be selected if necessary. If dependency=false (the default) then the
> bundle is also a requirement for the resolver if the feature is to be installed.
>
> I agree with you that it would be great to move to a more general way that then
> also works in different environments.
> Some time ago I wrote down some ideas for a feature replacement that is less
> karaf specific.
> http://liquid-reality.de/display/liquid/Design+repository+based+features+for+Apache+Karaf
>
> The main things features provide:
>
> - List of bundles to choose from
> - List of bundles to install (requirements)
> - Configs to install
> - Conditionally install additional bundles if other features are present
>
> The first three things can already be done without features:
> - An OBR index can supply the list of bundles to choose from ( I already started
> to provide OBR repos in some projects like Aries RSA)
> - We could use a list of top level bundles as initial requirements
> - A bundle can require other bundles using Require-Bundle headers. This could
> allow feature like bundles that list other top level bundles
> - Configurations can be provided inside of bundles using the Configurer spec and
> impl from enroute
>
> For conditional bundles there is no replacement outside of features.
>
> So we could develop a replacement of features that works in all OSGi
> environments. It is just matter of knowledge and effort to implement this.
>
> You can see in the CXF-DOSGi SOAP sample what can already be done with OBR and
> a resolver:
> https://github.com/apache/cxf-dosgi/blob/master/samples/soap/soap.bndrun#L1-L41
> The runbundles are automatically determined by the resolver.
> As you can see it is already possible but still quite a bit more effort than
> with karaf features at the moment.
>
> Christian
>
>
>
> 2017-06-14 7:49 GMT+02:00 David Leangen <apache@leangen.net
> <ma...@leangen.net>>:
>
>
> Hi!
>
> I am trying to wrap my head around the differences between an OBR and a
> Karaf Feature. The concepts seem to be overlapping.
>
> An OBR has an index of the contained bundles, as well as meta information,
> which includes requirements and capabilities. An OBR is therefore very
> useful for resolving bundles, and partitioning bundles into some kind of
> category. It can also be versioned, and can contained different versions of
> bundles. An OBR could potentially be used to keep snapshots of system
> releases. I believe that this is somewhat how Apache ACE works. (A
> Distribution can be rolled back by simply referring to a different OBR and
> allowing the system to re-resolve.) The actual bundles need to be stored
> somewhere. The OBR index needs to provide links to that storage.
>
> A Karaf Feature is basically an index of bundles (and configurations), too.
> I think that it can also be versioned, and can contain different versions of
> bundles. Like an OBR, it is very useful for partitioning bundles into some
> kind of category, so the groups of bundles can be manipulated as a single
> unit. Just like an OBR, the Karaf Feature also needs to provide a link to
> the bundles. AFAIU, resolution is done somehow in Karaf, based on the
> bundles available via the Features, so in the end the entire mechanism seems
> almost identical to what the OBR is doing.
>
>
> So many similarities!
>
>
> I understand that a Feature can include configurations, which is nice, but
> why have a competing non-official standard against an official standard? If
> configurations is the only problem, then why not build it on top of OBRs,
> rather than creating something completely new and different and competing?
>
> Is it to try to force lock-in to Karaf? Or am I completely missing something?
>
>
> Thanks for explaining! :-)
>
>
> Cheers,
> =David
>
>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf Feature vs. OBR
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi David,
I think the reason is more that features in karaf used to work a lot
simpler in the start. They were simply a list of bundles to install. Over
time features got more and more abilities.
So it is less to lock in people and more simply a history matter.
Since karaf 4 features use the felix resolver. You can imagine a feature as
a mix of obr and requirements for the resolver.
If a bundle in a feature is marked as dependency=true then it behaves in
the same way as a bundle listed in an OBR if the feature is installed. It
is simply there to be selected if necessary. If dependency=false (the
default) then the bundle is also a requirement for the resolver if the
feature is to be installed.
I agree with you that it would be great to move to a more general way that
then also works in different environments.
Some time ago I wrote down some ideas for a feature replacement that is
less karaf specific.
http://liquid-reality.de/display/liquid/Design+repository+based+features+for+Apache+Karaf
The main things features provide:
- List of bundles to choose from
- List of bundles to install (requirements)
- Configs to install
- Conditionally install additional bundles if other features are present
The first three things can already be done without features:
- An OBR index can supply the list of bundles to choose from ( I already
started to provide OBR repos in some projects like Aries RSA)
- We could use a list of top level bundles as initial requirements
- A bundle can require other bundles using Require-Bundle headers. This
could allow feature like bundles that list other top level bundles
- Configurations can be provided inside of bundles using the Configurer
spec and impl from enroute
For conditional bundles there is no replacement outside of features.
So we could develop a replacement of features that works in all OSGi
environments. It is just matter of knowledge and effort to implement this.
You can see in the CXF-DOSGi SOAP sample what can already be done with OBR
and a resolver:
https://github.com/apache/cxf-dosgi/blob/master/samples/soap/soap.bndrun#L1-L41
The runbundles are automatically determined by the resolver.
As you can see it is already possible but still quite a bit more effort
than with karaf features at the moment.
Christian
2017-06-14 7:49 GMT+02:00 David Leangen <ap...@leangen.net>:
>
> Hi!
>
> I am trying to wrap my head around the differences between an OBR and a
> Karaf Feature. The concepts seem to be overlapping.
>
> An OBR has an index of the contained bundles, as well as meta information,
> which includes requirements and capabilities. An OBR is therefore very
> useful for resolving bundles, and partitioning bundles into some kind of
> category. It can also be versioned, and can contained different versions of
> bundles. An OBR could potentially be used to keep snapshots of system
> releases. I believe that this is somewhat how Apache ACE works. (A
> Distribution can be rolled back by simply referring to a different OBR and
> allowing the system to re-resolve.) The actual bundles need to be stored
> somewhere. The OBR index needs to provide links to that storage.
>
> A Karaf Feature is basically an index of bundles (and configurations),
> too. I think that it can also be versioned, and can contain different
> versions of bundles. Like an OBR, it is very useful for partitioning
> bundles into some kind of category, so the groups of bundles can be
> manipulated as a single unit. Just like an OBR, the Karaf Feature also
> needs to provide a link to the bundles. AFAIU, resolution is done somehow
> in Karaf, based on the bundles available via the Features, so in the end
> the entire mechanism seems almost identical to what the OBR is doing.
>
>
> So many similarities!
>
>
> I understand that a Feature can include configurations, which is nice, but
> why have a competing non-official standard against an official standard? If
> configurations is the only problem, then why not build it on top of OBRs,
> rather than creating something completely new and different and competing?
>
> Is it to try to force lock-in to Karaf? Or am I completely missing
> something?
>
>
> Thanks for explaining! :-)
>
>
> Cheers,
> =David
>
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: Karaf Feature vs. OBR
Posted by David Leangen <ap...@leangen.net>.
Hi Christian,
>> I don’t know. I think I rather like the idea of the curated repositories that I know won’t shift over time.
> You need both. During active development you want to use the newest dependency .. at least for your own artifacts .. sometimes also for remote ones. Then once you do a release you of course want it to be completely static and not change over time.
I think that the approach you refer to excludes the possibility of Continuous Deployment, though. Every commit is a “release”, at least in theory.
Using the approach you mention, you would have to do a maven release every single day, if not multiple times per day, which is not reasonable IMO. Or are you referring to something different?
Cheers,
=David
Re: Karaf Feature vs. OBR
Posted by Christian Schneider <ch...@die-schneider.net>.
You need both. During active development you want to use the newest
dependency .. at least for your own artifacts .. sometimes also for remote
ones. Then once you do a release you of course want it to be completely
static and not change over time.
Christian
2017-06-15 13:12 GMT+02:00 David Leangen <ap...@leangen.net>:
>
> Hi Christian,
>
> I don’t know. I think I rather like the idea of the curated repositories
> that I know won’t shift over time. I can package up a small OBR (with URLs
> related to the index file) and deploy it somewhere. I can have very fine
> grained management of my “sets” (I’ll refrain from calling them
> “features”), including versioned “sets” so I can easily roll back to a
> previously known working state if needed.
>
> I believe that this is how bnd/enroute is intended to work.
>
> Otherwise, you get pure chaos, like the npm world, which works one day and
> is broken the next because a butterfly in China flapped its wings.
>
> (By the way, OBR or Maven, either way I don’t mind, but it’s the
> predictability/stability that is important to me.)
>
>
> Cheers,
> =David
>
>
>
> On Jun 15, 2017, at 4:54 PM, Christian Schneider <ch...@die-schneider.net>
> wrote:
>
> Without mvn urls you can either use file urls or http urls. Both suck in
> some important regards:
>
> A file url requires that the refered jar resides near the OBR. Today most
> people work with maven repos. So a natural place for an artifact is the
> local maven repository. It is difficult to point a file url to it as it
> will always be depending on the user setup.
> As a workaround file urls worked well for me in bndtools. What I did was
> to always generrate my OBR content during the build so it was no problem
> that the urls depend on my setup.
> This means though that you can never publish the contents of the OBR. The
> good thing is that you can work with maven SNAPSHOTs this way.
>
> For http urls you can point to the http url of a jar in a maven repo like
> maven central .. there are many downsides though.
> 1. The url is absolute. So you always point to a certain external
> resource. So you need additional measures if you want to cache the artifact
> locally.
> 2. For maven snapshots the urls in a remote maven repo always change. So
> you can not point to the newest snapshot which you want to do during active
> development
> 3. These absolute urls make you dependent on the external repo
> availability and you need to open your firewall to access it.
>
> mvn urls on the other hand work extremly well in enterprise environments
> as you can leverage local mvn proxies. You can also access secured
> reporitories that require authentication.
>
> So if you really try to use plain OBR without mvn urls in a maven build it
> sucks a lot. This is why Peter did the mvn based repos in bndtools 3.3.0. I
> discussed a lot with him about these. The current state works quite well
> but unfortunately it is completely outside the OBR spec. So I hope we see
> improvements in the spec so we can have both a solution that is sec
> compliant and works well for maven builds.
>
> Actually I think this is not only about maven builds. It is about using
> maven repos which is also very relevant for gradle and other builds.
>
> Christian
>
>
>
> 2017-06-15 8:51 GMT+02:00 David Leangen <ap...@leangen.net>:
>
>>
>> Hi Christian,
>>
>> Thanks for this information.
>>
>> > There is one big downside to OBR unfortunately. Inside OBR the content
>> of bundles needs to be refered as a url. While karaf can work with mvn urls
>> other systems like bndtools can not. Now the problem is that you can not
>> populate an OBR well without maven urls if your artifacts reside in maven
>> and you also want to use maven SNAPSHOTs.
>>
>> My understanding is that this is very much by design. The reason is to
>> have a “strongly” curated repository to promote well-behaved and
>> predictable builds and deployments.
>>
>> I could be wrong. Maybe would be good to verify with some of the alliance
>> peeps.
>>
>>
>> > Another solution is to consider the OBR just as a cache and define the
>> list of bundles in a pom. Bndtools is going that way and I think karaf
>> could do the same. So a feature could simply point to a pom or when
>> deployed to maven we could assume to use the pom of the project the feature
>> resides in as default. This would allow to simply define OBRs by using a
>> pom.
>>
>> You think bndtools is going that way? Or rather, they are just trying to
>> bring in more Maven people? I don’t understand what the purpose would be.
>> If the bundles are already defined in the OBR, why have a second list?
>>
>>
>> Cheers,
>> =David
>>
>>
>>
>> > On Jun 15, 2017, at 3:18 PM, Christian Schneider <
>> chris@die-schneider.net> wrote:
>> >
>> > There is one big downside to OBR unfortunately. Inside OBR the content
>> of bundles needs to be refered as a url. While karaf can work with mvn urls
>> other systems like bndtools can not. Now the problem is that you can not
>> populate an OBR well without maven urls if your artifacts reside in maven
>> and you also want to use maven SNAPSHOTs.
>> >
>> > So I think there is a gap in OBR that needs to be closed. One solution
>> would be to add the mvn urls to the spec so they are universally accepted.
>> >
>> > Another solution is to consider the OBR just as a cache and define the
>> list of bundles in a pom. Bndtools is going that way and I think karaf
>> could do the same. So a feature could simply point to a pom or when
>> deployed to maven we could assume to use the pom of the project the feature
>> resides in as default. This would allow to simply define OBRs by using a
>> pom.
>> >
>> > Christian
>> >
>> >
>> > 2017-06-14 23:58 GMT+02:00 David Leangen <ap...@leangen.net>:
>> >
>> > Hi Guillaume,
>> >
>> > Thank you for this assessment.
>> >
>> > I agree that Features adds value. Your post explains a lot of good
>> reasons why this is so.
>> >
>> > My question is more about “why compete with OBR?”. Instead of embracing
>> OBR and working on top of it, it seems that Features want to replace it.
>> This is causing me to have to make a lot of choices in my deployment
>> mechanism.
>> >
>> > Features could be really helpful for deployment by managing OBRs,
>> configurations, and other deployment information. They could also manage
>> versioning better etc. Maybe something like what Apache ACE was trying to
>> do. However, instead of “adding” value, currently Features are completely
>> replacing OBR, which I find interesting. But I understand that there is
>> some legacy to this. Now that it works, it would take some momentum to move
>> to a more standards-based approach.
>> >
>> >
>> > My current issue is: how can I use Features for Continuous Deployment?
>> I am having trouble with automation. That is what got me interested in the
>> idea behind the Features…
>> >
>> >
>> > Cheers,
>> > =David
>> >
>> >
>> >
>> >> On Jun 15, 2017, at 6:38 AM, Guillaume Nodet <gn...@apache.org>
>> wrote:
>> >>
>> >> So if you consider an OBR as being a collection of resources, each
>> resource having capabilities and requirements, then a feature repository is
>> an OBR repository, it's just the syntax is more concise.
>> >> If you want to look at what the repository look like, you can launch
>> the following command in karaf:
>> >> > feature:install --store resolution.json --verbose --simulate scr
>> >>
>> >> Then, look at the resolution.json file, it will contain the OBR
>> repository used by the resolver in a json format. The xml syntax would be
>> slightly different of course, and a bit more verbose too, but roughly the
>> same data.
>> >> I do think the features syntax is a bit more understandable.
>> >>
>> >> But you do not want to compare OBR and features. I haven't seen any
>> OBR repository used which would contain other things than just OSGi bundles.
>> >> Features is more a deployment artifact than an OSGi bundle, so it's
>> more to be compared with OSGi subsystems.
>> >>
>> >> With pure OBR, you can't group bundles together, you usually don't
>> want to edit such a repository file manually, so at the end, you can never
>> really hack the content. It has to be generated, and is mostly generated
>> only from a set of OSGi bundles. You can't capture all the constraints by
>> using bundles only.
>> >>
>> >> 2017-06-14 7:49 GMT+02:00 David Leangen <ap...@leangen.net>:
>> >>
>> >> Hi!
>> >>
>> >> I am trying to wrap my head around the differences between an OBR and
>> a Karaf Feature. The concepts seem to be overlapping.
>> >>
>> >> An OBR has an index of the contained bundles, as well as meta
>> information, which includes requirements and capabilities. An OBR is
>> therefore very useful for resolving bundles, and partitioning bundles into
>> some kind of category. It can also be versioned, and can contained
>> different versions of bundles. An OBR could potentially be used to keep
>> snapshots of system releases. I believe that this is somewhat how Apache
>> ACE works. (A Distribution can be rolled back by simply referring to a
>> different OBR and allowing the system to re-resolve.) The actual bundles
>> need to be stored somewhere. The OBR index needs to provide links to that
>> storage.
>> >>
>> >> A Karaf Feature is basically an index of bundles (and configurations),
>> too. I think that it can also be versioned, and can contain different
>> versions of bundles. Like an OBR, it is very useful for partitioning
>> bundles into some kind of category, so the groups of bundles can be
>> manipulated as a single unit. Just like an OBR, the Karaf Feature also
>> needs to provide a link to the bundles. AFAIU, resolution is done somehow
>> in Karaf, based on the bundles available via the Features, so in the end
>> the entire mechanism seems almost identical to what the OBR is doing.
>> >>
>> >>
>> >> So many similarities!
>> >>
>> >>
>> >> I understand that a Feature can include configurations, which is nice,
>> but why have a competing non-official standard against an official
>> standard? If configurations is the only problem, then why not build it on
>> top of OBRs, rather than creating something completely new and different
>> and competing?
>> >>
>> >> Is it to try to force lock-in to Karaf? Or am I completely missing
>> something?
>> >>
>> >>
>> >> Thanks for explaining! :-)
>> >>
>> >>
>> >> Cheers,
>> >> =David
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> ------------------------
>> >> Guillaume Nodet
>> >>
>> >
>> >
>> >
>> >
>> > --
>> > --
>> > Christian Schneider
>> > http://www.liquid-reality.de
>> >
>> > Open Source Architect
>> > http://www.talend.com
>>
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
>
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: Karaf Feature vs. OBR
Posted by David Leangen <ap...@leangen.net>.
Hi Christian,
I don’t know. I think I rather like the idea of the curated repositories that I know won’t shift over time. I can package up a small OBR (with URLs related to the index file) and deploy it somewhere. I can have very fine grained management of my “sets” (I’ll refrain from calling them “features”), including versioned “sets” so I can easily roll back to a previously known working state if needed.
I believe that this is how bnd/enroute is intended to work.
Otherwise, you get pure chaos, like the npm world, which works one day and is broken the next because a butterfly in China flapped its wings.
(By the way, OBR or Maven, either way I don’t mind, but it’s the predictability/stability that is important to me.)
Cheers,
=David
> On Jun 15, 2017, at 4:54 PM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> Without mvn urls you can either use file urls or http urls. Both suck in some important regards:
>
> A file url requires that the refered jar resides near the OBR. Today most people work with maven repos. So a natural place for an artifact is the local maven repository. It is difficult to point a file url to it as it will always be depending on the user setup.
> As a workaround file urls worked well for me in bndtools. What I did was to always generrate my OBR content during the build so it was no problem that the urls depend on my setup.
> This means though that you can never publish the contents of the OBR. The good thing is that you can work with maven SNAPSHOTs this way.
>
> For http urls you can point to the http url of a jar in a maven repo like maven central .. there are many downsides though.
> 1. The url is absolute. So you always point to a certain external resource. So you need additional measures if you want to cache the artifact locally.
> 2. For maven snapshots the urls in a remote maven repo always change. So you can not point to the newest snapshot which you want to do during active development
> 3. These absolute urls make you dependent on the external repo availability and you need to open your firewall to access it.
>
> mvn urls on the other hand work extremly well in enterprise environments as you can leverage local mvn proxies. You can also access secured reporitories that require authentication.
>
> So if you really try to use plain OBR without mvn urls in a maven build it sucks a lot. This is why Peter did the mvn based repos in bndtools 3.3.0. I discussed a lot with him about these. The current state works quite well but unfortunately it is completely outside the OBR spec. So I hope we see improvements in the spec so we can have both a solution that is sec compliant and works well for maven builds.
>
> Actually I think this is not only about maven builds. It is about using maven repos which is also very relevant for gradle and other builds.
>
> Christian
>
>
>
> 2017-06-15 8:51 GMT+02:00 David Leangen <apache@leangen.net <ma...@leangen.net>>:
>
> Hi Christian,
>
> Thanks for this information.
>
> > There is one big downside to OBR unfortunately. Inside OBR the content of bundles needs to be refered as a url. While karaf can work with mvn urls other systems like bndtools can not. Now the problem is that you can not populate an OBR well without maven urls if your artifacts reside in maven and you also want to use maven SNAPSHOTs.
>
> My understanding is that this is very much by design. The reason is to have a “strongly” curated repository to promote well-behaved and predictable builds and deployments.
>
> I could be wrong. Maybe would be good to verify with some of the alliance peeps.
>
>
> > Another solution is to consider the OBR just as a cache and define the list of bundles in a pom. Bndtools is going that way and I think karaf could do the same. So a feature could simply point to a pom or when deployed to maven we could assume to use the pom of the project the feature resides in as default. This would allow to simply define OBRs by using a pom.
>
> You think bndtools is going that way? Or rather, they are just trying to bring in more Maven people? I don’t understand what the purpose would be. If the bundles are already defined in the OBR, why have a second list?
>
>
> Cheers,
> =David
>
>
>
> > On Jun 15, 2017, at 3:18 PM, Christian Schneider <chris@die-schneider.net <ma...@die-schneider.net>> wrote:
> >
> > There is one big downside to OBR unfortunately. Inside OBR the content of bundles needs to be refered as a url. While karaf can work with mvn urls other systems like bndtools can not. Now the problem is that you can not populate an OBR well without maven urls if your artifacts reside in maven and you also want to use maven SNAPSHOTs.
> >
> > So I think there is a gap in OBR that needs to be closed. One solution would be to add the mvn urls to the spec so they are universally accepted.
> >
> > Another solution is to consider the OBR just as a cache and define the list of bundles in a pom. Bndtools is going that way and I think karaf could do the same. So a feature could simply point to a pom or when deployed to maven we could assume to use the pom of the project the feature resides in as default. This would allow to simply define OBRs by using a pom.
> >
> > Christian
> >
> >
> > 2017-06-14 23:58 GMT+02:00 David Leangen <apache@leangen.net <ma...@leangen.net>>:
> >
> > Hi Guillaume,
> >
> > Thank you for this assessment.
> >
> > I agree that Features adds value. Your post explains a lot of good reasons why this is so.
> >
> > My question is more about “why compete with OBR?”. Instead of embracing OBR and working on top of it, it seems that Features want to replace it. This is causing me to have to make a lot of choices in my deployment mechanism.
> >
> > Features could be really helpful for deployment by managing OBRs, configurations, and other deployment information. They could also manage versioning better etc. Maybe something like what Apache ACE was trying to do. However, instead of “adding” value, currently Features are completely replacing OBR, which I find interesting. But I understand that there is some legacy to this. Now that it works, it would take some momentum to move to a more standards-based approach.
> >
> >
> > My current issue is: how can I use Features for Continuous Deployment? I am having trouble with automation. That is what got me interested in the idea behind the Features…
> >
> >
> > Cheers,
> > =David
> >
> >
> >
> >> On Jun 15, 2017, at 6:38 AM, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
> >>
> >> So if you consider an OBR as being a collection of resources, each resource having capabilities and requirements, then a feature repository is an OBR repository, it's just the syntax is more concise.
> >> If you want to look at what the repository look like, you can launch the following command in karaf:
> >> > feature:install --store resolution.json --verbose --simulate scr
> >>
> >> Then, look at the resolution.json file, it will contain the OBR repository used by the resolver in a json format. The xml syntax would be slightly different of course, and a bit more verbose too, but roughly the same data.
> >> I do think the features syntax is a bit more understandable.
> >>
> >> But you do not want to compare OBR and features. I haven't seen any OBR repository used which would contain other things than just OSGi bundles.
> >> Features is more a deployment artifact than an OSGi bundle, so it's more to be compared with OSGi subsystems.
> >>
> >> With pure OBR, you can't group bundles together, you usually don't want to edit such a repository file manually, so at the end, you can never really hack the content. It has to be generated, and is mostly generated only from a set of OSGi bundles. You can't capture all the constraints by using bundles only.
> >>
> >> 2017-06-14 7:49 GMT+02:00 David Leangen <apache@leangen.net <ma...@leangen.net>>:
> >>
> >> Hi!
> >>
> >> I am trying to wrap my head around the differences between an OBR and a Karaf Feature. The concepts seem to be overlapping.
> >>
> >> An OBR has an index of the contained bundles, as well as meta information, which includes requirements and capabilities. An OBR is therefore very useful for resolving bundles, and partitioning bundles into some kind of category. It can also be versioned, and can contained different versions of bundles. An OBR could potentially be used to keep snapshots of system releases. I believe that this is somewhat how Apache ACE works. (A Distribution can be rolled back by simply referring to a different OBR and allowing the system to re-resolve.) The actual bundles need to be stored somewhere. The OBR index needs to provide links to that storage.
> >>
> >> A Karaf Feature is basically an index of bundles (and configurations), too. I think that it can also be versioned, and can contain different versions of bundles. Like an OBR, it is very useful for partitioning bundles into some kind of category, so the groups of bundles can be manipulated as a single unit. Just like an OBR, the Karaf Feature also needs to provide a link to the bundles. AFAIU, resolution is done somehow in Karaf, based on the bundles available via the Features, so in the end the entire mechanism seems almost identical to what the OBR is doing.
> >>
> >>
> >> So many similarities!
> >>
> >>
> >> I understand that a Feature can include configurations, which is nice, but why have a competing non-official standard against an official standard? If configurations is the only problem, then why not build it on top of OBRs, rather than creating something completely new and different and competing?
> >>
> >> Is it to try to force lock-in to Karaf? Or am I completely missing something?
> >>
> >>
> >> Thanks for explaining! :-)
> >>
> >>
> >> Cheers,
> >> =David
> >>
> >>
> >>
> >>
> >>
> >> --
> >> ------------------------
> >> Guillaume Nodet
> >>
> >
> >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de <http://www.liquid-reality.de/>
> >
> > Open Source Architect
> > http://www.talend.com <http://www.talend.com/>
>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: Karaf Feature vs. OBR
Posted by Christian Schneider <ch...@die-schneider.net>.
Without mvn urls you can either use file urls or http urls. Both suck in
some important regards:
A file url requires that the refered jar resides near the OBR. Today most
people work with maven repos. So a natural place for an artifact is the
local maven repository. It is difficult to point a file url to it as it
will always be depending on the user setup.
As a workaround file urls worked well for me in bndtools. What I did was to
always generrate my OBR content during the build so it was no problem that
the urls depend on my setup.
This means though that you can never publish the contents of the OBR. The
good thing is that you can work with maven SNAPSHOTs this way.
For http urls you can point to the http url of a jar in a maven repo like
maven central .. there are many downsides though.
1. The url is absolute. So you always point to a certain external resource.
So you need additional measures if you want to cache the artifact locally.
2. For maven snapshots the urls in a remote maven repo always change. So
you can not point to the newest snapshot which you want to do during active
development
3. These absolute urls make you dependent on the external repo availability
and you need to open your firewall to access it.
mvn urls on the other hand work extremly well in enterprise environments as
you can leverage local mvn proxies. You can also access secured
reporitories that require authentication.
So if you really try to use plain OBR without mvn urls in a maven build it
sucks a lot. This is why Peter did the mvn based repos in bndtools 3.3.0. I
discussed a lot with him about these. The current state works quite well
but unfortunately it is completely outside the OBR spec. So I hope we see
improvements in the spec so we can have both a solution that is sec
compliant and works well for maven builds.
Actually I think this is not only about maven builds. It is about using
maven repos which is also very relevant for gradle and other builds.
Christian
2017-06-15 8:51 GMT+02:00 David Leangen <ap...@leangen.net>:
>
> Hi Christian,
>
> Thanks for this information.
>
> > There is one big downside to OBR unfortunately. Inside OBR the content
> of bundles needs to be refered as a url. While karaf can work with mvn urls
> other systems like bndtools can not. Now the problem is that you can not
> populate an OBR well without maven urls if your artifacts reside in maven
> and you also want to use maven SNAPSHOTs.
>
> My understanding is that this is very much by design. The reason is to
> have a “strongly” curated repository to promote well-behaved and
> predictable builds and deployments.
>
> I could be wrong. Maybe would be good to verify with some of the alliance
> peeps.
>
>
> > Another solution is to consider the OBR just as a cache and define the
> list of bundles in a pom. Bndtools is going that way and I think karaf
> could do the same. So a feature could simply point to a pom or when
> deployed to maven we could assume to use the pom of the project the feature
> resides in as default. This would allow to simply define OBRs by using a
> pom.
>
> You think bndtools is going that way? Or rather, they are just trying to
> bring in more Maven people? I don’t understand what the purpose would be.
> If the bundles are already defined in the OBR, why have a second list?
>
>
> Cheers,
> =David
>
>
>
> > On Jun 15, 2017, at 3:18 PM, Christian Schneider <
> chris@die-schneider.net> wrote:
> >
> > There is one big downside to OBR unfortunately. Inside OBR the content
> of bundles needs to be refered as a url. While karaf can work with mvn urls
> other systems like bndtools can not. Now the problem is that you can not
> populate an OBR well without maven urls if your artifacts reside in maven
> and you also want to use maven SNAPSHOTs.
> >
> > So I think there is a gap in OBR that needs to be closed. One solution
> would be to add the mvn urls to the spec so they are universally accepted.
> >
> > Another solution is to consider the OBR just as a cache and define the
> list of bundles in a pom. Bndtools is going that way and I think karaf
> could do the same. So a feature could simply point to a pom or when
> deployed to maven we could assume to use the pom of the project the feature
> resides in as default. This would allow to simply define OBRs by using a
> pom.
> >
> > Christian
> >
> >
> > 2017-06-14 23:58 GMT+02:00 David Leangen <ap...@leangen.net>:
> >
> > Hi Guillaume,
> >
> > Thank you for this assessment.
> >
> > I agree that Features adds value. Your post explains a lot of good
> reasons why this is so.
> >
> > My question is more about “why compete with OBR?”. Instead of embracing
> OBR and working on top of it, it seems that Features want to replace it.
> This is causing me to have to make a lot of choices in my deployment
> mechanism.
> >
> > Features could be really helpful for deployment by managing OBRs,
> configurations, and other deployment information. They could also manage
> versioning better etc. Maybe something like what Apache ACE was trying to
> do. However, instead of “adding” value, currently Features are completely
> replacing OBR, which I find interesting. But I understand that there is
> some legacy to this. Now that it works, it would take some momentum to move
> to a more standards-based approach.
> >
> >
> > My current issue is: how can I use Features for Continuous Deployment? I
> am having trouble with automation. That is what got me interested in the
> idea behind the Features…
> >
> >
> > Cheers,
> > =David
> >
> >
> >
> >> On Jun 15, 2017, at 6:38 AM, Guillaume Nodet <gn...@apache.org> wrote:
> >>
> >> So if you consider an OBR as being a collection of resources, each
> resource having capabilities and requirements, then a feature repository is
> an OBR repository, it's just the syntax is more concise.
> >> If you want to look at what the repository look like, you can launch
> the following command in karaf:
> >> > feature:install --store resolution.json --verbose --simulate scr
> >>
> >> Then, look at the resolution.json file, it will contain the OBR
> repository used by the resolver in a json format. The xml syntax would be
> slightly different of course, and a bit more verbose too, but roughly the
> same data.
> >> I do think the features syntax is a bit more understandable.
> >>
> >> But you do not want to compare OBR and features. I haven't seen any
> OBR repository used which would contain other things than just OSGi bundles.
> >> Features is more a deployment artifact than an OSGi bundle, so it's
> more to be compared with OSGi subsystems.
> >>
> >> With pure OBR, you can't group bundles together, you usually don't want
> to edit such a repository file manually, so at the end, you can never
> really hack the content. It has to be generated, and is mostly generated
> only from a set of OSGi bundles. You can't capture all the constraints by
> using bundles only.
> >>
> >> 2017-06-14 7:49 GMT+02:00 David Leangen <ap...@leangen.net>:
> >>
> >> Hi!
> >>
> >> I am trying to wrap my head around the differences between an OBR and a
> Karaf Feature. The concepts seem to be overlapping.
> >>
> >> An OBR has an index of the contained bundles, as well as meta
> information, which includes requirements and capabilities. An OBR is
> therefore very useful for resolving bundles, and partitioning bundles into
> some kind of category. It can also be versioned, and can contained
> different versions of bundles. An OBR could potentially be used to keep
> snapshots of system releases. I believe that this is somewhat how Apache
> ACE works. (A Distribution can be rolled back by simply referring to a
> different OBR and allowing the system to re-resolve.) The actual bundles
> need to be stored somewhere. The OBR index needs to provide links to that
> storage.
> >>
> >> A Karaf Feature is basically an index of bundles (and configurations),
> too. I think that it can also be versioned, and can contain different
> versions of bundles. Like an OBR, it is very useful for partitioning
> bundles into some kind of category, so the groups of bundles can be
> manipulated as a single unit. Just like an OBR, the Karaf Feature also
> needs to provide a link to the bundles. AFAIU, resolution is done somehow
> in Karaf, based on the bundles available via the Features, so in the end
> the entire mechanism seems almost identical to what the OBR is doing.
> >>
> >>
> >> So many similarities!
> >>
> >>
> >> I understand that a Feature can include configurations, which is nice,
> but why have a competing non-official standard against an official
> standard? If configurations is the only problem, then why not build it on
> top of OBRs, rather than creating something completely new and different
> and competing?
> >>
> >> Is it to try to force lock-in to Karaf? Or am I completely missing
> something?
> >>
> >>
> >> Thanks for explaining! :-)
> >>
> >>
> >> Cheers,
> >> =David
> >>
> >>
> >>
> >>
> >>
> >> --
> >> ------------------------
> >> Guillaume Nodet
> >>
> >
> >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: Karaf Feature vs. OBR
Posted by David Leangen <ap...@leangen.net>.
Hi Christian,
Thanks for this information.
> There is one big downside to OBR unfortunately. Inside OBR the content of bundles needs to be refered as a url. While karaf can work with mvn urls other systems like bndtools can not. Now the problem is that you can not populate an OBR well without maven urls if your artifacts reside in maven and you also want to use maven SNAPSHOTs.
My understanding is that this is very much by design. The reason is to have a “strongly” curated repository to promote well-behaved and predictable builds and deployments.
I could be wrong. Maybe would be good to verify with some of the alliance peeps.
> Another solution is to consider the OBR just as a cache and define the list of bundles in a pom. Bndtools is going that way and I think karaf could do the same. So a feature could simply point to a pom or when deployed to maven we could assume to use the pom of the project the feature resides in as default. This would allow to simply define OBRs by using a pom.
You think bndtools is going that way? Or rather, they are just trying to bring in more Maven people? I don’t understand what the purpose would be. If the bundles are already defined in the OBR, why have a second list?
Cheers,
=David
> On Jun 15, 2017, at 3:18 PM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> There is one big downside to OBR unfortunately. Inside OBR the content of bundles needs to be refered as a url. While karaf can work with mvn urls other systems like bndtools can not. Now the problem is that you can not populate an OBR well without maven urls if your artifacts reside in maven and you also want to use maven SNAPSHOTs.
>
> So I think there is a gap in OBR that needs to be closed. One solution would be to add the mvn urls to the spec so they are universally accepted.
>
> Another solution is to consider the OBR just as a cache and define the list of bundles in a pom. Bndtools is going that way and I think karaf could do the same. So a feature could simply point to a pom or when deployed to maven we could assume to use the pom of the project the feature resides in as default. This would allow to simply define OBRs by using a pom.
>
> Christian
>
>
> 2017-06-14 23:58 GMT+02:00 David Leangen <ap...@leangen.net>:
>
> Hi Guillaume,
>
> Thank you for this assessment.
>
> I agree that Features adds value. Your post explains a lot of good reasons why this is so.
>
> My question is more about “why compete with OBR?”. Instead of embracing OBR and working on top of it, it seems that Features want to replace it. This is causing me to have to make a lot of choices in my deployment mechanism.
>
> Features could be really helpful for deployment by managing OBRs, configurations, and other deployment information. They could also manage versioning better etc. Maybe something like what Apache ACE was trying to do. However, instead of “adding” value, currently Features are completely replacing OBR, which I find interesting. But I understand that there is some legacy to this. Now that it works, it would take some momentum to move to a more standards-based approach.
>
>
> My current issue is: how can I use Features for Continuous Deployment? I am having trouble with automation. That is what got me interested in the idea behind the Features…
>
>
> Cheers,
> =David
>
>
>
>> On Jun 15, 2017, at 6:38 AM, Guillaume Nodet <gn...@apache.org> wrote:
>>
>> So if you consider an OBR as being a collection of resources, each resource having capabilities and requirements, then a feature repository is an OBR repository, it's just the syntax is more concise.
>> If you want to look at what the repository look like, you can launch the following command in karaf:
>> > feature:install --store resolution.json --verbose --simulate scr
>>
>> Then, look at the resolution.json file, it will contain the OBR repository used by the resolver in a json format. The xml syntax would be slightly different of course, and a bit more verbose too, but roughly the same data.
>> I do think the features syntax is a bit more understandable.
>>
>> But you do not want to compare OBR and features. I haven't seen any OBR repository used which would contain other things than just OSGi bundles.
>> Features is more a deployment artifact than an OSGi bundle, so it's more to be compared with OSGi subsystems.
>>
>> With pure OBR, you can't group bundles together, you usually don't want to edit such a repository file manually, so at the end, you can never really hack the content. It has to be generated, and is mostly generated only from a set of OSGi bundles. You can't capture all the constraints by using bundles only.
>>
>> 2017-06-14 7:49 GMT+02:00 David Leangen <ap...@leangen.net>:
>>
>> Hi!
>>
>> I am trying to wrap my head around the differences between an OBR and a Karaf Feature. The concepts seem to be overlapping.
>>
>> An OBR has an index of the contained bundles, as well as meta information, which includes requirements and capabilities. An OBR is therefore very useful for resolving bundles, and partitioning bundles into some kind of category. It can also be versioned, and can contained different versions of bundles. An OBR could potentially be used to keep snapshots of system releases. I believe that this is somewhat how Apache ACE works. (A Distribution can be rolled back by simply referring to a different OBR and allowing the system to re-resolve.) The actual bundles need to be stored somewhere. The OBR index needs to provide links to that storage.
>>
>> A Karaf Feature is basically an index of bundles (and configurations), too. I think that it can also be versioned, and can contain different versions of bundles. Like an OBR, it is very useful for partitioning bundles into some kind of category, so the groups of bundles can be manipulated as a single unit. Just like an OBR, the Karaf Feature also needs to provide a link to the bundles. AFAIU, resolution is done somehow in Karaf, based on the bundles available via the Features, so in the end the entire mechanism seems almost identical to what the OBR is doing.
>>
>>
>> So many similarities!
>>
>>
>> I understand that a Feature can include configurations, which is nice, but why have a competing non-official standard against an official standard? If configurations is the only problem, then why not build it on top of OBRs, rather than creating something completely new and different and competing?
>>
>> Is it to try to force lock-in to Karaf? Or am I completely missing something?
>>
>>
>> Thanks for explaining! :-)
>>
>>
>> Cheers,
>> =David
>>
>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
Re: Karaf Feature vs. OBR
Posted by Christian Schneider <ch...@die-schneider.net>.
There is one big downside to OBR unfortunately. Inside OBR the content of
bundles needs to be refered as a url. While karaf can work with mvn urls
other systems like bndtools can not. Now the problem is that you can not
populate an OBR well without maven urls if your artifacts reside in maven
and you also want to use maven SNAPSHOTs.
So I think there is a gap in OBR that needs to be closed. One solution
would be to add the mvn urls to the spec so they are universally accepted.
Another solution is to consider the OBR just as a cache and define the list
of bundles in a pom. Bndtools is going that way and I think karaf could do
the same. So a feature could simply point to a pom or when deployed to
maven we could assume to use the pom of the project the feature resides in
as default. This would allow to simply define OBRs by using a pom.
Christian
2017-06-14 23:58 GMT+02:00 David Leangen <ap...@leangen.net>:
>
> Hi Guillaume,
>
> Thank you for this assessment.
>
> I agree that Features adds value. Your post explains a lot of good reasons
> why this is so.
>
> My question is more about “why compete with OBR?”. Instead of embracing
> OBR and working on top of it, it seems that Features want to replace it.
> This is causing me to have to make a lot of choices in my deployment
> mechanism.
>
> Features could be really helpful for deployment by managing OBRs,
> configurations, and other deployment information. They could also manage
> versioning better etc. Maybe something like what Apache ACE was trying to
> do. However, instead of “adding” value, currently Features are completely
> replacing OBR, which I find interesting. But I understand that there is
> some legacy to this. Now that it works, it would take some momentum to move
> to a more standards-based approach.
>
>
> My current issue is: how can I use Features for Continuous Deployment? I
> am having trouble with automation. That is what got me interested in the
> idea behind the Features…
>
>
> Cheers,
> =David
>
>
>
> On Jun 15, 2017, at 6:38 AM, Guillaume Nodet <gn...@apache.org> wrote:
>
> So if you consider an OBR as being a collection of resources, each
> resource having capabilities and requirements, then a feature repository is
> an OBR repository, it's just the syntax is more concise.
> If you want to look at what the repository look like, you can launch the
> following command in karaf:
> > feature:install --store resolution.json --verbose --simulate scr
>
> Then, look at the resolution.json file, it will contain the OBR repository
> used by the resolver in a json format. The xml syntax would be slightly
> different of course, and a bit more verbose too, but roughly the same data.
> I do think the features syntax is a bit more understandable.
>
> But you do not want to compare OBR and features. I haven't seen any OBR
> repository used which would contain other things than just OSGi bundles.
> Features is more a deployment artifact than an OSGi bundle, so it's more
> to be compared with OSGi subsystems.
>
> With pure OBR, you can't group bundles together, you usually don't want to
> edit such a repository file manually, so at the end, you can never really
> hack the content. It has to be generated, and is mostly generated only
> from a set of OSGi bundles. You can't capture all the constraints by using
> bundles only.
>
> 2017-06-14 7:49 GMT+02:00 David Leangen <ap...@leangen.net>:
>
>>
>> Hi!
>>
>> I am trying to wrap my head around the differences between an OBR and a
>> Karaf Feature. The concepts seem to be overlapping.
>>
>> An OBR has an index of the contained bundles, as well as meta
>> information, which includes requirements and capabilities. An OBR is
>> therefore very useful for resolving bundles, and partitioning bundles into
>> some kind of category. It can also be versioned, and can contained
>> different versions of bundles. An OBR could potentially be used to keep
>> snapshots of system releases. I believe that this is somewhat how Apache
>> ACE works. (A Distribution can be rolled back by simply referring to a
>> different OBR and allowing the system to re-resolve.) The actual bundles
>> need to be stored somewhere. The OBR index needs to provide links to that
>> storage.
>>
>> A Karaf Feature is basically an index of bundles (and configurations),
>> too. I think that it can also be versioned, and can contain different
>> versions of bundles. Like an OBR, it is very useful for partitioning
>> bundles into some kind of category, so the groups of bundles can be
>> manipulated as a single unit. Just like an OBR, the Karaf Feature also
>> needs to provide a link to the bundles. AFAIU, resolution is done somehow
>> in Karaf, based on the bundles available via the Features, so in the end
>> the entire mechanism seems almost identical to what the OBR is doing.
>>
>>
>> So many similarities!
>>
>>
>> I understand that a Feature can include configurations, which is nice,
>> but why have a competing non-official standard against an official
>> standard? If configurations is the only problem, then why not build it on
>> top of OBRs, rather than creating something completely new and different
>> and competing?
>>
>> Is it to try to force lock-in to Karaf? Or am I completely missing
>> something?
>>
>>
>> Thanks for explaining! :-)
>>
>>
>> Cheers,
>> =David
>>
>>
>>
>
>
> --
> ------------------------
> Guillaume Nodet
>
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: Karaf Feature vs. OBR
Posted by David Leangen <ap...@leangen.net>.
Hi Steiner,
Thanks for this information.
> On Jun 16, 2017, at 3:53 AM, Steinar Bang <sb...@dod.no> wrote:
>
> It doesn't involve features, except for the installation, but I do this:
> 1. Use maven to build the bundles (and the features)
> 2. Use a -SNAPSHOT version
I’ll look into this approach. There are a few interesting things in there. Thanks for sharing.
However, I have come to the conclusion that the Maven SNAPSHOTs are incompatible with Continuous Deployment. I’m not saying that they are bad, just that it is for a different type of development process where you develop locally for a while, then do a “big” release, rather than incremental daily releases.
There is a presentation that explains the concept very well. The related information starts from 13:40 in this video about Apache ACE:
https://www.youtube.com/watch?v=4S_zvgG_MLw <https://www.youtube.com/watch?v=4S_zvgG_MLw>
Cheers,
=David
Re: Making karaf update snapshots from remote repositories Was: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
To summarize my experiences so far:
1. I have a travis ci build that does maven snapshot deploys using ftp
to a directory on the same server where karaf is running.
2. I serve the maven repository area out with HTTP and HTTPS using
nginx.
3. I added the maven repository served out by nginx like so:
config:edit org.ops4j.pax.url.mvn
config:property-append org.ops4j.pax.url.mvn.repositories ", https://maven.bang.priv.no/repository/@snapshots, http://maven.vaadin.com/vaadin-addons"
config:property-set org.ops4j.pax.url.mvn.globalUpdatePolicy always
config:update
4. After this, I could install my webapp with these commands:
feature:repo-add mvn:no.priv.bang.ukelonn/ukelonn.karaf/LATEST/xml/features
feature:install ukelonn-db-postgresql
feature:install ukelonn
bundle:watch *
5. After this, the webapp started and run
6. I did a new travis-ci build that deployed a new snapshot version
into the maven repository
7. The snapshot changes weren't picked up automatically by karaf
(ie. "bundle:watch *" had no effect)
8. Giving the command "bundle:update" for each bundle made the bundles
reload from the new snapshot:
bundle:update no.priv.bang.ukelonn.api
bundle:update no.priv.bang.ukelonn.db.liquibase
bundle:update no.priv.bang.ukelonn.db.postgresql
bundle:update no.priv.bang.ukelonn
9. I uninstalled and reinstalled karaf to start with a clean slate
10. I added the repository where travis-ci deploys the snapshots with a
file URL (since it is on the same machine as karaf is running)
config:edit org.ops4j.pax.url.mvn
config:property-append org.ops4j.pax.url.mvn.repositories ", file:///usr/local/www-maven/repository/@snapshots, http://maven.vaadin.com/vaadin-addons"
config:property-set org.ops4j.pax.url.mvn.globalUpdatePolicy always
config:update
11. I reinstalled my webapp, this time from the "file:" repository
feature:repo-add mvn:no.priv.bang.ukelonn/ukelonn.karaf/LATEST/xml/features
feature:install ukelonn-db-postgresql
feature:install ukelonn
bundle:watch *
12. I deployed a new maven snapshot version to the "file:" repository
from a travis-ci build
13. At the time of writing its approximately 30 minutes since the
travis-ci job completed, but karaf hasn't loaded any new snapshots
yet, so "bundle:watch *" doesn't seem to work for snapshots that are
loaded from a "file:" maven repository, that isn't the maven local
repository
Re: Making karaf update snapshots from remote repositories Was: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
>>>>> Steinar Bang <sb...@dod.no>:
> [snip!]
>> But the conclusion is that I'm pretty sure neither bundle:watch nor
>> bundle:update works for watching a remote repository, or update a
>> bundle installed from a remote repository.
> (But I will be very happy to be proved wrong...)
The bundle:watch command doesn't work for watching snapshots being
deployed to a remote repository.
However, the bundle:update command works just fine for updating a
snapshot installed from a remote maven repository.
Pushing changes to master, triggered a new travis build that deployed to
the maven repository at https://maven.bang.priv.no/repository/
I did "ssh -p 8101 karaf@localhost" to log into the karaf console, and
then gave the following commands to update all of my snapshot bundles:
bundle:update no.priv.bang.ukelonn.api
bundle:update no.priv.bang.ukelonn.db.liquibase
bundle:update no.priv.bang.ukelonn.db.postgresql
bundle:update no.priv.bang.ukelonn
After this I verified that the GUI of the webapp showed the new changes
I wanted deployed.
It isn't "bundle:watch *", but it is a lot simpler than doing git pull
and "mvn clean install" as user karaf (I did it by creating shell
scripts I started from the karaf console).
(After looking at the code, I have no idea why "bundle:update" works,
but I can see that it does...)
Re: Making karaf update snapshots from remote repositories Was: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
[snip!]
> But the conclusion is that I'm pretty sure neither bundle:watch nor
> bundle:update works for watching a remote repository, or update a
> bundle installed from a remote repository.
(But I will be very happy to be proved wrong...)
Re: Making karaf update snapshots from remote repositories Was: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
[snip!]
> But as far as I can tell from the HTTP server access log, nothing is
> polling maven.bang.priv.no.
As far as I can tell from the source code of karaf 4.1.2[1][2],
bundle:watch only works for files in the local repository.
The bundle:update command also looks like it only works for a local
file, unless the --raw flag is used[3] (But the "--raw" flag
description looks unrelated to local vs. possibly remote, and there is
no guarantee that it works for remote locations. It's just that I can't
be positive that it doesn't work).
I know that the bundle:install command works for a remote repository,
because I've installed my application from a remote repository (that is:
I've installed the application using feature:install, so I'm just
assuming that installing of bundles from remote repositories work), but
I can't tell how it works, because it disappears into
BundleContext.install() to do the installation[4].
But the conclusion is that I'm pretty sure neither bundle:watch nor
bundle:update works for watching a remote repository, or update a bundle
installed from a remote repository.
References:
[1] <https://github.com/apache/karaf/blob/karaf-4.1.x/bundle/core/src/main/java/org/apache/karaf/bundle/core/internal/BundleWatcherImpl.java#L156>
[2] <https://github.com/apache/karaf/blob/karaf-4.1.x/bundle/core/src/main/java/org/apache/karaf/bundle/core/internal/BundleWatcherImpl.java#L216>
[3] <https://github.com/apache/karaf/blob/karaf-4.1.x/bundle/core/src/main/java/org/apache/karaf/bundle/command/Update.java#L67>
[4] <https://github.com/apache/karaf/blob/karaf-4.1.x/bundle/core/src/main/java/org/apache/karaf/bundle/command/Install.java#L84>
Making karaf update snapshots from remote repositories Was: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
> Now I've done it differently (...and perhaps more correctly...?):
> 1. I've installed karaf-4.1.2 on a debian 9 "squeeze" system, using the
> debian package created by this script: https://github.com/steinarb/karaf-deb-packaging
> The .deb package creates the user "karaf" that karaf is running as
> 2. I've used "ssh -p 8101 karaf@localhost" to log in to the console of
> karaf and then
> a. Changed the config to add the snapshot repository, and set the
> globalUpdatePolicy to always:
> config:edit org.ops4j.pax.url.mvn
> config:property-append org.ops4j.pax.url.mvn.repositories ", https://maven.bang.priv.no/repository/@snapshots, http://maven.vaadin.com/vaadin-addons"
> config:property-set org.ops4j.pax.url.mvn.globalUpdatePolicy always
> config:update
> b. I've then installed my application (pulled in from the snapshot
> repository added above):
> feature:repo-add mvn:no.priv.bang.ukelonn/ukelonn.karaf/LATEST/xml/features
> feature:install ukelonn-db-postgresql
> feature:install ukelonn
> c. I've set karaf up to listen for snapshot changes
> bundle:watch *
> The application starts up fine, and everything is downloaded from the
> snapshot repository.
> But as far as I can tell from the logs of the repository, there is
> nothing accessing https://maven.bang.priv.no/repository/ to check if
> there are updates to the snapshots.
I added "aether.updateCheckManager.sessionState=false" to
/etc/karaf/system.properties as outlined in [1].
Then I stopped and started the karaf service
systemctl stop karaf
systemctl start karaf
But as far as I can tell from the HTTP server access log, nothing is
polling maven.bang.priv.no.
References:
[1] <https://stackoverflow.com/questions/24791950/how-to-work-with-frequent-local-snapshot-bundle-deployments-on-karaf#comment67335318_24796028>
Re: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
>>>>> Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> You can change the update global policy in etc/org.ops4j.pax.url.mvn.cfg.
> Ok, on karaf 4.1.2, I've now set the global update policy, and added a
> remote repo that contains snapshots:
Now I've done it differently (...and perhaps more correctly...?):
1. I've installed karaf-4.1.2 on a debian 9 "squeeze" system, using the
debian package created by this script: https://github.com/steinarb/karaf-deb-packaging
The .deb package creates the user "karaf" that karaf is running as
2. I've used "ssh -p 8101 karaf@localhost" to log in to the console of
karaf and then
a. Changed the config to add the snapshot repository, and set the
globalUpdatePolicy to always:
config:edit org.ops4j.pax.url.mvn
config:property-append org.ops4j.pax.url.mvn.repositories ", https://maven.bang.priv.no/repository/@snapshots, http://maven.vaadin.com/vaadin-addons"
config:property-set org.ops4j.pax.url.mvn.globalUpdatePolicy always
config:update
b. I've then installed my application (pulled in from the snapshot
repository added above):
feature:repo-add mvn:no.priv.bang.ukelonn/ukelonn.karaf/LATEST/xml/features
feature:install ukelonn-db-postgresql
feature:install ukelonn
c. I've set karaf up to listen for snapshot changes
bundle:watch *
The application starts up fine, and everything is downloaded from the
snapshot repository.
But as far as I can tell from the logs of the repository, there is
nothing accessing https://maven.bang.priv.no/repository/ to check if
there are updates to the snapshots.
Re: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Jean-Baptiste Onofré <jb...@nanthrax.net>:
> You can change the update global policy in etc/org.ops4j.pax.url.mvn.cfg.
Ok, on karaf 4.1.2, I've now set the global update policy, and added a
remote repo that contains snapshots:
*** org.ops4j.pax.url.mvn.cfg 2017/08/18 13:58:10 1.1
--- org.ops4j.pax.url.mvn.cfg 2017/08/18 15:57:14
***************
*** 71,77 ****
# Use the default local repo (e.g.~/.m2/repository) as a "remote" repo
#org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote=false
! #org.ops4j.pax.url.mvn.globalUpdatePolicy=always
#
# Comma separated list of repositories scanned when resolving an artifact.
--- 71,77 ----
# Use the default local repo (e.g.~/.m2/repository) as a "remote" repo
#org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote=false
! org.ops4j.pax.url.mvn.globalUpdatePolicy=always
#
# Comma separated list of repositories scanned when resolving an artifact.
***************
*** 91,96 ****
--- 91,97 ----
# @id=repository.id : the id for the repository, just like in the settings.xml this is optional but recommended
#
org.ops4j.pax.url.mvn.repositories= \
+ https://maven.bang.priv.no/repository@snapshots, \
http://artifactory.lampiris.be/remote-repos@snapshots, \
http://repo1.maven.org/maven2@id=central, \
http://repository.springsource.com/maven/bundles/release@id=spring.ebr.release, \
I've then done
bundle:watch *
But as far as I can see from the access log, karaf hasn't visited
https://maven.bang.priv.no/repository yet.
Is there something more I have to do?
Re: Karaf Feature vs. OBR
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
You can change the update global policy in etc/org.ops4j.pax.url.mvn.cfg.
Regards
JB
On 06/15/2017 10:06 PM, Steinar Bang wrote:
>>>>>> Jean-Baptiste Onofré <jb...@nanthrax.net>:
>
>> did you try the global update policy to always to get the new SNAPSHOT
>> from remote repo ?
>
> No, I thought listening for SNAPSHOTS was only possible on a local
> repo... at least I thought so up until now...:-)
>
> That would simplify deploy (much simpler than my proposed webhooks
> solution), but it requires the build server to have access to a maven
> repo that also is accessible from the karaf server, and I don't have
> that right now.
>
>> By the way, I'm adding "deployment tooling" in Cave right now
>> (allowing to explode a kar, create meta feature assembling existing
>> features, ...).
>
> Interesting! Will study!
> https://karaf.apache.org/manual/cave/latest-4/
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
>>>>> Steinar Bang <sb...@dod.no>:
> [snip!]
>> So, no success yet at totally automating the deployment from a
>> travis-ci build.
>> I still need to to "bundle:update" from the karaf console on each bundle
>> I want updated after a new snapshot has been added.
> The still-in-flux REST API of the webconsole offers a possibility:
> http://felix.apache.org/documentation/subprojects/apache-felix-web-console/web-console-restful-api.html
> I have verified that this causes a bundle to update on my development
> machine:
> curl -X POST --data "action=update" --basic -u karaf:karaf http://localhost:8181/system/console/bundles/no.priv.bang.ukelonn
> So in theory I could now create a shell script (or something) that would
> POST an update to all affected bundles, and modify the travis.yml file
> to run this script after completion of the snapshot deployment.
I was able to use the rest-maven-plugin to accomplish this, by adding
this to the <pluginManagement> of the parent pom
https://github.com/steinarb/ukelonn/blob/scratch/call-karaf-console-rest-api-to-update-bundle-at-the-end-of-deploy/pom.xml#L320
and then adding the following to each of the bundle projects:
https://github.com/steinarb/ukelonn/blob/scratch/call-karaf-console-rest-api-to-update-bundle-at-the-end-of-deploy/ukelonn.api/pom.xml#L68
https://github.com/steinarb/ukelonn/blob/scratch/call-karaf-console-rest-api-to-update-bundle-at-the-end-of-deploy/ukelonn.bundle.db.liquibase/pom.xml#L98
https://github.com/steinarb/ukelonn/blob/scratch/call-karaf-console-rest-api-to-update-bundle-at-the-end-of-deploy/ukelonn.bundle.db.test/pom.xml#L169
https://github.com/steinarb/ukelonn/blob/scratch/call-karaf-console-rest-api-to-update-bundle-at-the-end-of-deploy/ukelonn.bundle.db.postgresql/pom.xml#L154
https://github.com/steinarb/ukelonn/blob/scratch/call-karaf-console-rest-api-to-update-bundle-at-the-end-of-deploy/ukelonn.bundle/pom.xml#L237
> The downside is that I would have to install the webconsole, and expose
> it to the internet, and I'm not sure I want to do that... I prefer to
> limit access to admin features to what's absolutely necessary.
The downsides are still valid.
But I have verfied locally that this works.
Re: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
[snip!]
> So, no success yet at totally automating the deployment from a
> travis-ci build.
> I still need to to "bundle:update" from the karaf console on each bundle
> I want updated after a new snapshot has been added.
The still-in-flux REST API of the webconsole offers a possibility:
http://felix.apache.org/documentation/subprojects/apache-felix-web-console/web-console-restful-api.html
I have verified that this causes a bundle to update on my development
machine:
curl -X POST --data "action=update" --basic -u karaf:karaf http://localhost:8181/system/console/bundles/no.priv.bang.ukelonn
So in theory I could now create a shell script (or something) that would
POST an update to all affected bundles, and modify the travis.yml file
to run this script after completion of the snapshot deployment.
The downside is that I would have to install the webconsole, and expose
it to the internet, and I'm not sure I want to do that... I prefer to
limit access to admin features to what's absolutely necessary.
Re: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
>>>>> Guillaume Nodet <gn...@apache.org>:
>> Fwiw, bundle:watch is very specific and only check the local repository, so
>> it won't work if you upload a new snapshot on a remote repository.
> I was sort of hoping it would work for a different maven repo in the
> local file system, which is what I currently have.
I tried one (actually two experiments):
1. Made the repository deployed to by travis-ci karaf's local
repository.
Using the same local repository as maven builds worked when I tried
it out on my development machine (after I had made the repository
writable by karaf).
But it failed when using the repository deployed to by travis-ci on
my production machine, because karaf was unable to recognize the
deployed snapshots as snapshots in the local repository (actual
repositories have a different snapshot structure to the local
repository)
2. Since I was in experimentation mode I tried making the repository
are both the local repository and added it as a repository, like so:
config:edit org.ops4j.pax.url.mvn
config:property-set org.ops4j.pax.url.mvn.localRepository /var/www-maven/repository
config:property-append org.ops4j.pax.url.mvn.repositories ", file:///var/www-maven/repository, http://maven.vaadin.com/vaadin-addons"
config:update
But this made karaf terribly confused:
karaf@root()> feature:repo-add mvn:no.priv.bang.ukelonn/ukelonn.karaf/LATEST/xml/featuresAdding feature url mvn:no.priv.bang.ukelonn/ukelonn.karaf/LATEST/xml/features
Error executing command: Error resolving artifact no.priv.bang.ukelonn:ukelonn.karaf:xml:features:1.0.0-SNAPSHOT: [Could not transfer artifact no.priv.bang.ukelonn:ukelonn.karaf:xml:features:1.0.0-SNAPSHOT from/to repo_1276108016 (http://artifactory.lampiris.be/remote-repos/): artifactory.lampiris.be, Could not find artifact no.priv.bang.ukelonn:ukelonn.karaf:xml:features:1.0.0-SNAPSHOT in apache (http://repository.apache.org/content/groups/snapshots-group/), Could not find artifact no.priv.bang.ukelonn:ukelonn.karaf:xml:features:1.0.0-SNAPSHOT in sonatype.snapshots.deploy (https://oss.sonatype.org/content/repositories/snapshots/), Could not find artifact no.priv.bang.ukelonn:ukelonn.karaf:xml:features:1.0.0-SNAPSHOT in ops4j.sonatype.snapshots.deploy (https://oss.sonatype.org/content/repositories/ops4j-snapshots/), Could not find artifact no.priv.bang.ukelonn:ukelonn.karaf:xml:features:1.0.0-SNAPSHOT in spring-ebr-repository (http://repository.springsource.com/maven/bundles/external/)] : mvn:no.priv.bang.ukelonn/ukelonn.karaf/LATEST/xml/features
karaf@root()>
(I didn't expect the second experiement to work. I just tried it out to
see what would happen...:-) )
So now I'm back to running with the https-URL pointing to the travis-ci
deployment repository added to the mvn.repositories setting:
config:edit org.ops4j.pax.url.mvn
config:property-append org.ops4j.pax.url.mvn.repositories ", https://maven.bang.priv.no/repository/@snapshots, http://maven.vaadin.com/vaadin-addons"
config:property-set org.ops4j.pax.url.mvn.globalUpdatePolicy always
config:update
So, no success yet at totally automating the deployment from a
travis-ci build.
I still need to to "bundle:update" from the karaf console on each bundle
I want updated after a new snapshot has been added.
Re: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Guillaume Nodet <gn...@apache.org>:
> Fwiw, bundle:watch is very specific and only check the local repository, so
> it won't work if you upload a new snapshot on a remote repository.
I was sort of hoping it would work for a different maven repo in the
local file system, which is what I currently have.
Re: Karaf Feature vs. OBR
Posted by Guillaume Nodet <gn...@apache.org>.
Fwiw, bundle:watch is very specific and only check the local repository, so
it won't work if you upload a new snapshot on a remote repository.
2017-08-31 20:44 GMT+02:00 Steinar Bang <sb...@dod.no>:
> >>>>> Steinar Bang <sb...@dod.no>:
> >>>>> Steinar Bang <sb...@dod.no>:
> >>>>> Jean-Baptiste Onofré <jb...@nanthrax.net>:
>
> >>> By the way, I'm adding "deployment tooling" in Cave right now
> >>> (allowing to explode a kar, create meta feature assembling existing
> >>> features, ...).
>
> >> Interesting! Will study!
> >> https://karaf.apache.org/manual/cave/latest-4/
>
> > So now I see three ways to do continous delivery:
> > 1. Snapshot builds from travis, triggered by github changes, deploying
> > to a packagecloud account[1] (a free package cloud account will
> > probably serve my humble needs...)
>
> I tried this: I created a 14 day trial account on packagecloud, and
> tried to deploy my code there. That failed because the server side at
> packagecloud didn't like maven artifact attachment with extension .xml.
>
> This means that all of my bundle projects (which have a karaf feature
> attached) as well as the project with packaging pom, that aggregates all
> of my bundles' features into a feature repository, failed to deploy.
>
> The packagecloud people filed a bug on that but couldn't promise to have
> it fixed during what was left of my trial period.
>
> > 2. Installing jenkins on the same server karaf is running, and using
> > cave to refer to the /home/jenkins/.m2/repository
> > 3. Running jenkins on a different computer and rsync the
> > /home/jenkins/.m2/repository to the server karaf is running and use
> > cave to make karaf listen to /home/jenkins/.m2/repository (I tried
> > rsyncing my manual builds from my own account on a different
> > computer to the karaf account on the karaf server,
> > ie. /home/karaf/.m2/repository, but that got a lot of issues
> > wrt. file ownership and access. Doing it to the same account and on
> > a different account from the karaf account should resolve this)
>
> I ended up doing none of the above. I ended up doing:
> 4. Set up an ftp server on the same machine where karaf was running,
> and set up travis-ci to deploy to that repository, and then adding
> the file-URL pointing to the deployment area as a maven repository
> in the karaf config. After a travis-ci deployment I have to log
> into the karaf console and do "bundle:update" on each bundle I
> would like refreshed
>
> This works, and is a lot simpler than what I did before. But it's still
> not fully automated (I still have to do the manual "bundle:update"
> commands).
>
>
>
--
------------------------
Guillaume Nodet
Re: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
>>>>> Steinar Bang <sb...@dod.no>:
>>>>> Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>> By the way, I'm adding "deployment tooling" in Cave right now
>>> (allowing to explode a kar, create meta feature assembling existing
>>> features, ...).
>> Interesting! Will study!
>> https://karaf.apache.org/manual/cave/latest-4/
> So now I see three ways to do continous delivery:
> 1. Snapshot builds from travis, triggered by github changes, deploying
> to a packagecloud account[1] (a free package cloud account will
> probably serve my humble needs...)
I tried this: I created a 14 day trial account on packagecloud, and
tried to deploy my code there. That failed because the server side at
packagecloud didn't like maven artifact attachment with extension .xml.
This means that all of my bundle projects (which have a karaf feature
attached) as well as the project with packaging pom, that aggregates all
of my bundles' features into a feature repository, failed to deploy.
The packagecloud people filed a bug on that but couldn't promise to have
it fixed during what was left of my trial period.
> 2. Installing jenkins on the same server karaf is running, and using
> cave to refer to the /home/jenkins/.m2/repository
> 3. Running jenkins on a different computer and rsync the
> /home/jenkins/.m2/repository to the server karaf is running and use
> cave to make karaf listen to /home/jenkins/.m2/repository (I tried
> rsyncing my manual builds from my own account on a different
> computer to the karaf account on the karaf server,
> ie. /home/karaf/.m2/repository, but that got a lot of issues
> wrt. file ownership and access. Doing it to the same account and on
> a different account from the karaf account should resolve this)
I ended up doing none of the above. I ended up doing:
4. Set up an ftp server on the same machine where karaf was running,
and set up travis-ci to deploy to that repository, and then adding
the file-URL pointing to the deployment area as a maven repository
in the karaf config. After a travis-ci deployment I have to log
into the karaf console and do "bundle:update" on each bundle I
would like refreshed
This works, and is a lot simpler than what I did before. But it's still
not fully automated (I still have to do the manual "bundle:update"
commands).
Re: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@dod.no>:
>>>>> Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> By the way, I'm adding "deployment tooling" in Cave right now
>> (allowing to explode a kar, create meta feature assembling existing
>> features, ...).
> Interesting! Will study!
> https://karaf.apache.org/manual/cave/latest-4/
So now I see three ways to do continous delivery:
1. Snapshot builds from travis, triggered by github changes, deploying
to a package cloud account[1] (a free package cloud account will
probably serve my humble needs...)
2. Installing jenkins on the same server karaf is running, and using
cave to refer to the /home/jenkins/.m2/repository
3. Running jenkins on a different computer and rsync the
/home/jenkins/.m2/repository to the server karaf is running and use
cave to make karaf listen to /home/jenkins/.m2/repository (I tried
rsyncing my manual builds from my own account on a different
computer to the karaf account on the karaf server,
ie. /home/karaf/.m2/repository, but that got a lot of issues
wrt. file ownership and access. Doing it to the same account and on
a different account from the karaf account should resolve this)
References:
[1] <https://packagecloud.io/pricing>
Re: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Jean-Baptiste Onofré <jb...@nanthrax.net>:
> did you try the global update policy to always to get the new SNAPSHOT
> from remote repo ?
No, I thought listening for SNAPSHOTS was only possible on a local
repo... at least I thought so up until now...:-)
That would simplify deploy (much simpler than my proposed webhooks
solution), but it requires the build server to have access to a maven
repo that also is accessible from the karaf server, and I don't have
that right now.
> By the way, I'm adding "deployment tooling" in Cave right now
> (allowing to explode a kar, create meta feature assembling existing
> features, ...).
Interesting! Will study!
https://karaf.apache.org/manual/cave/latest-4/
Re: Karaf Feature vs. OBR
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
did you try the global update policy to always to get the new SNAPSHOT from
remote repo ?
By the way, I'm adding "deployment tooling" in Cave right now (allowing to
explode a kar, create meta feature assembling existing features, ...).
Regards
JB
On 06/15/2017 08:53 PM, Steinar Bang wrote:
>>>>>> David Leangen <ap...@leangen.net>:
>
>> My current issue is: how can I use Features for Continuous Deployment?
>> I am having trouble with automation. That is what got me interested in
>> the idea behind the Features…
>
> It doesn't involve features, except for the installation, but I do this:
> 1. Use maven to build the bundles (and the features)
> 2. Use a -SNAPSHOT version
> 3. Create a new version and push to github
> 4. As the user karaf is running under (actually user "karaf" on my
> debian server):
> a. Clone the github repo
> b. Install the features
> c. Do the command "bundle:watch *" (which makes karaf keep an eye
> out for updates to -SNAPSHOT version'ed bundles in user
> "karaf"'s local repository, ie ~karaf/.m2/repository/ )
> 5. When I want to deploy an update, I:
> a. Push it to github
> b. On the server "ssh -p 8101 karaf@localhost" (to log in as user
> karaf)
> c. From the karaf console run shell script that cd's to the cloned
> git project, do a git pull, followed by a "mvn clean install"
> d. Once new versions of the -SNAPSHOT bundles are installed into
> ~karaf/.m2/repository, karaf will pick them up and reinstall
> them
>
> My intention is to replace the manual step 5b. with a github webhook
> (triggering the shell script doing the build from the karaf console has
> been a proof of concept for this).
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf Feature vs. OBR
Posted by Steinar Bang <sb...@dod.no>.
>>>>> David Leangen <ap...@leangen.net>:
> My current issue is: how can I use Features for Continuous Deployment?
> I am having trouble with automation. That is what got me interested in
> the idea behind the Features…
It doesn't involve features, except for the installation, but I do this:
1. Use maven to build the bundles (and the features)
2. Use a -SNAPSHOT version
3. Create a new version and push to github
4. As the user karaf is running under (actually user "karaf" on my
debian server):
a. Clone the github repo
b. Install the features
c. Do the command "bundle:watch *" (which makes karaf keep an eye
out for updates to -SNAPSHOT version'ed bundles in user
"karaf"'s local repository, ie ~karaf/.m2/repository/ )
5. When I want to deploy an update, I:
a. Push it to github
b. On the server "ssh -p 8101 karaf@localhost" (to log in as user
karaf)
c. From the karaf console run shell script that cd's to the cloned
git project, do a git pull, followed by a "mvn clean install"
d. Once new versions of the -SNAPSHOT bundles are installed into
~karaf/.m2/repository, karaf will pick them up and reinstall
them
My intention is to replace the manual step 5b. with a github webhook
(triggering the shell script doing the build from the karaf console has
been a proof of concept for this).
Re: Karaf Feature vs. OBR
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
It's what I said: for me there's interaction not competition.
Again, we fully support OBR as resource repos in etc/org.apache.karaf.features.cfg.
Regards
JB
On 06/15/2017 08:27 AM, Guillaume Nodet wrote:
> Again, I'm not sure why you see features competing with OBR.
> We do actually leverage OBR internally, and we can also leverage it externally
> though it's not much advertised, but it was hinted by Jean-Baptiste when he
> talked about Cave.
>
> OBR is the repository specification, so it defines a Repository interface. We
> do have multiple implementations of it in Karaf : the standardized XML one, a
> JSON based repository implementation and an in-vm one.
>
> A feature descriptor supports the <resource-repository> element. The content of
> this element is an url to a OBR repository (eventually prefixed with json: or
> xml:). All features defined in the features repository will behave as if they
> have the resources defined in the OBR repository with <bundle
> dependency="true">xxx</bundle>.
>
> You can also provide a list of global repositories and configure it in
> etc/org.apache.karaf.features.cfg with the resourceRepositories key (a command
> separated list of urls).
>
> Also, there's absolutely no value in the OBR bundle description compared to a
> manifest. It contains the same information in a different form and is usually
> generated from the manifest. Fwiw, when a feature has a reference to a bundle,
> we do generate the OSGi Resource from the manifest directly without using the
> OBR xml description, but it's the same.
>
> I'm really not sure what we could do to leverage OBR more...
>
>
> 2017-06-14 23:58 GMT+02:00 David Leangen <apache@leangen.net
> <ma...@leangen.net>>:
>
>
> Hi Guillaume,
>
> Thank you for this assessment.
>
> I agree that Features adds value. Your post explains a lot of good reasons
> why this is so.
>
> My question is more about “why compete with OBR?”. Instead of embracing OBR
> and working on top of it, it seems that Features want to replace it. This is
> causing me to have to make a lot of choices in my deployment mechanism.
>
> Features could be really helpful for deployment by managing OBRs,
> configurations, and other deployment information. They could also manage
> versioning better etc. Maybe something like what Apache ACE was trying to
> do. However, instead of “adding” value, currently Features are completely
> replacing OBR, which I find interesting. But I understand that there is some
> legacy to this. Now that it works, it would take some momentum to move to a
> more standards-based approach.
>
>
> My current issue is: how can I use Features for Continuous Deployment? I am
> having trouble with automation. That is what got me interested in the idea
> behind the Features…
>
>
> Cheers,
> =David
>
>
>
>> On Jun 15, 2017, at 6:38 AM, Guillaume Nodet <gnodet@apache.org
>> <ma...@apache.org>> wrote:
>>
>> So if you consider an OBR as being a collection of resources, each
>> resource having capabilities and requirements, then a feature repository
>> is an OBR repository, it's just the syntax is more concise.
>> If you want to look at what the repository look like, you can launch the
>> following command in karaf:
>> > feature:install--store resolution.json --verbose --simulate scr
>>
>> Then, look at the resolution.json file, it will contain the OBR repository
>> used by the resolver in a json format. The xml syntax would be slightly
>> different of course, and a bit more verbose too, but roughly the same data.
>> I do think the features syntax is a bit more understandable.
>>
>> But you do not want to compare OBR and features. I haven't seen any OBR
>> repository used which would contain other things than just OSGi bundles.
>> Features is more a deployment artifact than an OSGi bundle, so it's more
>> to be compared with OSGi subsystems.
>>
>> With pure OBR, you can't group bundles together, you usually don't want to
>> edit such a repository file manually, so at the end, you can never really
>> hack the content. It has to be generated, and is mostly generated only
>> from a set of OSGi bundles. You can't capture all the constraints by
>> using bundles only.
>>
>> 2017-06-14 7:49 GMT+02:00 David Leangen <apache@leangen.net
>> <ma...@leangen.net>>:
>>
>>
>> Hi!
>>
>> I am trying to wrap my head around the differences between an OBR and
>> a Karaf Feature. The concepts seem to be overlapping.
>>
>> An OBR has an index of the contained bundles, as well as meta
>> information, which includes requirements and capabilities. An OBR is
>> therefore very useful for resolving bundles, and partitioning bundles
>> into some kind of category. It can also be versioned, and can
>> contained different versions of bundles. An OBR could potentially be
>> used to keep snapshots of system releases. I believe that this is
>> somewhat how Apache ACE works. (A Distribution can be rolled back by
>> simply referring to a different OBR and allowing the system to
>> re-resolve.) The actual bundles need to be stored somewhere. The OBR
>> index needs to provide links to that storage.
>>
>> A Karaf Feature is basically an index of bundles (and configurations),
>> too. I think that it can also be versioned, and can contain different
>> versions of bundles. Like an OBR, it is very useful for partitioning
>> bundles into some kind of category, so the groups of bundles can be
>> manipulated as a single unit. Just like an OBR, the Karaf Feature also
>> needs to provide a link to the bundles. AFAIU, resolution is done
>> somehow in Karaf, based on the bundles available via the Features, so
>> in the end the entire mechanism seems almost identical to what the OBR
>> is doing.
>>
>>
>> So many similarities!
>>
>>
>> I understand that a Feature can include configurations, which is nice,
>> but why have a competing non-official standard against an official
>> standard? If configurations is the only problem, then why not build it
>> on top of OBRs, rather than creating something completely new and
>> different and competing?
>>
>> Is it to try to force lock-in to Karaf? Or am I completely missing
>> something?
>>
>>
>> Thanks for explaining! :-)
>>
>>
>> Cheers,
>> =David
>>
>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>
>
>
>
> --
> ------------------------
> Guillaume Nodet
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf Feature vs. OBR
Posted by David Leangen <ap...@leangen.net>.
Hi Guillaume,
Ok, that gives me a lot to chew on for now. I’ll give it a good try before I make any more speculative comments. :-)
Cheers,
=David
> On Jun 15, 2017, at 5:23 PM, Guillaume Nodet <gn...@apache.org> wrote:
>
>
>
> 2017-06-15 9:00 GMT+02:00 David Leangen <apache@leangen.net <ma...@leangen.net>>:
>
> Thanks Guillaume. A lot of good food for thought.
>
>> Again, I'm not sure why you see features competing with OBR.
>
>
> Coming from bnd/EnRoute, in my build environment I can create different OBRs, and “release" to them. I can use a different OBR per workspace, which means that I can develop each “feature" separately, and release it to its own OBR. Thus, an OBR defines a “feature”.
>
> No, it defines a repository, and that's fine. A feature is more than a list of bundles.
> OBR is useful when you want to install individual bundles.
> For example, if you want to deploy a web application, you could write a feature which will have a dependency on the karaf "war" feature. When you install your feature, it will ensure the web app support is deployed correctly.
> With OBR, you'll have a dependency on the servlet api, so the servlet api bundle will be deployed, and that's all.
> Of course, if you're only interested in the simple use cases, you can use an OBR repo and it will work.
>
> If you want to experiment deployment based on an OBR repo + a requirement, you could use the following file and drop it in the deploy folder:
>
> <features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0 <http://karaf.apache.org/xmlns/features/v1.4.0>">
> <resource-repository>[url to the OBR repo]</resource-repository>
> <feature name="[feature name]" install="auto">
> <requirement>[the requirement]</requirement>
> </feature>
> </features>
>
> If that's really all you need, it should be very easy to write a small karaf command that would do the same with the 3 parameters: a name, and obr repo url and a requirement.
>
>
>
> What I would like to be able to do is simply push the OBR into my container, without having any extra layer. When I tried in the past, there were some bugs and it did not work out very successfully. Maybe things have changed since then…
>
> Using Apache ACE as an example, an OBR can be used in a way that is very similar to a Feature. It works extremely well in the EnRoute environment, and cuts down a lot of noise, IMO.
>
> I haven't used ACE since a long time. It has very strong limitations because it's based on DeploymentAdmin which do not support deploying a bundle with multiple versions. This is a show-stopper for me.
>
>
>> A feature descriptor supports the <resource-repository> element. The content of this element is an url to a OBR repository (eventually prefixed with json: or xml:). All features defined in the features repository will behave as if they have the resources defined in the OBR repository with <bundle dependency="true">xxx</bundle>.
>
>
> Ok, either I did not know that, or I forgot about that. I’ll take a look. IIRC I think this is what didn’t work for me when I tried some time ago.
>
> I'd be happy to fix any bug.
>
>
>> You can also provide a list of global repositories and configure it in etc/org.apache.karaf.features.cfg with the resourceRepositories key (a command separated list of urls).
>
>
> The problem with this approach is, unless something has changed, I have to restart my container each time there is a change. I would also have to figure out a way to push the changes to Karaf. Perhaps this is easier than I thought, but I did not find a good way last time I look into this.
>
> Yes, that's a limited support. The reason is see problem in using this with not much value. The first option is preferrable in Karaf imho.
>
>
>> Also, there's absolutely no value in the OBR bundle description compared to a manifest. It contains the same information in a different form and is usually generated from the manifest. Fwiw, when a feature has a reference to a bundle, we do generate the OSGi Resource from the manifest directly without using the OBR xml description, but it's the same.
>
> True, but then again my understanding is that a properly curated OBR should provide a set of bundles, and should not change (which is why the ID gets updated each time there is even a minor change). The information could very well come from the bundles, but if the bundles don’t change and the index is trusted, then the pre-parsed manifest info is already in the index, so it’s a duplicate effort to redo the parsing. No?
>
> Actually, I think it's faster to parse a manifest than to the OBR xml, given the verbosity of the xml. Plus, it's an additional file to manage, so it has to provide some value, else it's not worth the pain.
>
>
>
> Perhaps the Karaf/Maven way of thinking is very different from the bnd way? Or maybe there has been convergence over the past few years, but the tooling has not kept up? (That is what I am trying to figure out, since I don’t know Maven very deeply, and based on what I understand, I think I prefer the bnd way.)
>
> Yeah, karaf tooling is definitely lacking I think.
>
>
>
> Cheers,
> =David
>
>
>
>> On Jun 15, 2017, at 3:27 PM, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>
>> Again, I'm not sure why you see features competing with OBR.
>> We do actually leverage OBR internally, and we can also leverage it externally though it's not much advertised, but it was hinted by Jean-Baptiste when he talked about Cave.
>>
>> OBR is the repository specification, so it defines a Repository interface. We do have multiple implementations of it in Karaf : the standardized XML one, a JSON based repository implementation and an in-vm one.
>>
>> A feature descriptor supports the <resource-repository> element. The content of this element is an url to a OBR repository (eventually prefixed with json: or xml:). All features defined in the features repository will behave as if they have the resources defined in the OBR repository with <bundle dependency="true">xxx</bundle>.
>>
>> You can also provide a list of global repositories and configure it in etc/org.apache.karaf.features.cfg with the resourceRepositories key (a command separated list of urls).
>>
>> Also, there's absolutely no value in the OBR bundle description compared to a manifest. It contains the same information in a different form and is usually generated from the manifest. Fwiw, when a feature has a reference to a bundle, we do generate the OSGi Resource from the manifest directly without using the OBR xml description, but it's the same.
>>
>> I'm really not sure what we could do to leverage OBR more...
>>
>>
>> 2017-06-14 23:58 GMT+02:00 David Leangen <apache@leangen.net <ma...@leangen.net>>:
>>
>> Hi Guillaume,
>>
>> Thank you for this assessment.
>>
>> I agree that Features adds value. Your post explains a lot of good reasons why this is so.
>>
>> My question is more about “why compete with OBR?”. Instead of embracing OBR and working on top of it, it seems that Features want to replace it. This is causing me to have to make a lot of choices in my deployment mechanism.
>>
>> Features could be really helpful for deployment by managing OBRs, configurations, and other deployment information. They could also manage versioning better etc. Maybe something like what Apache ACE was trying to do. However, instead of “adding” value, currently Features are completely replacing OBR, which I find interesting. But I understand that there is some legacy to this. Now that it works, it would take some momentum to move to a more standards-based approach.
>>
>>
>> My current issue is: how can I use Features for Continuous Deployment? I am having trouble with automation. That is what got me interested in the idea behind the Features…
>>
>>
>> Cheers,
>> =David
>>
>>
>>
>>> On Jun 15, 2017, at 6:38 AM, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>>
>>> So if you consider an OBR as being a collection of resources, each resource having capabilities and requirements, then a feature repository is an OBR repository, it's just the syntax is more concise.
>>> If you want to look at what the repository look like, you can launch the following command in karaf:
>>> > feature:install --store resolution.json --verbose --simulate scr
>>>
>>> Then, look at the resolution.json file, it will contain the OBR repository used by the resolver in a json format. The xml syntax would be slightly different of course, and a bit more verbose too, but roughly the same data.
>>> I do think the features syntax is a bit more understandable.
>>>
>>> But you do not want to compare OBR and features. I haven't seen any OBR repository used which would contain other things than just OSGi bundles.
>>> Features is more a deployment artifact than an OSGi bundle, so it's more to be compared with OSGi subsystems.
>>>
>>> With pure OBR, you can't group bundles together, you usually don't want to edit such a repository file manually, so at the end, you can never really hack the content. It has to be generated, and is mostly generated only from a set of OSGi bundles. You can't capture all the constraints by using bundles only.
>>>
>>> 2017-06-14 7:49 GMT+02:00 David Leangen <apache@leangen.net <ma...@leangen.net>>:
>>>
>>> Hi!
>>>
>>> I am trying to wrap my head around the differences between an OBR and a Karaf Feature. The concepts seem to be overlapping.
>>>
>>> An OBR has an index of the contained bundles, as well as meta information, which includes requirements and capabilities. An OBR is therefore very useful for resolving bundles, and partitioning bundles into some kind of category. It can also be versioned, and can contained different versions of bundles. An OBR could potentially be used to keep snapshots of system releases. I believe that this is somewhat how Apache ACE works. (A Distribution can be rolled back by simply referring to a different OBR and allowing the system to re-resolve.) The actual bundles need to be stored somewhere. The OBR index needs to provide links to that storage.
>>>
>>> A Karaf Feature is basically an index of bundles (and configurations), too. I think that it can also be versioned, and can contain different versions of bundles. Like an OBR, it is very useful for partitioning bundles into some kind of category, so the groups of bundles can be manipulated as a single unit. Just like an OBR, the Karaf Feature also needs to provide a link to the bundles. AFAIU, resolution is done somehow in Karaf, based on the bundles available via the Features, so in the end the entire mechanism seems almost identical to what the OBR is doing.
>>>
>>>
>>> So many similarities!
>>>
>>>
>>> I understand that a Feature can include configurations, which is nice, but why have a competing non-official standard against an official standard? If configurations is the only problem, then why not build it on top of OBRs, rather than creating something completely new and different and competing?
>>>
>>> Is it to try to force lock-in to Karaf? Or am I completely missing something?
>>>
>>>
>>> Thanks for explaining! :-)
>>>
>>>
>>> Cheers,
>>> =David
>>>
>>>
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>>
>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>
>
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Karaf Feature vs. OBR
Posted by Guillaume Nodet <gn...@apache.org>.
2017-06-15 9:00 GMT+02:00 David Leangen <ap...@leangen.net>:
>
> Thanks Guillaume. A lot of good food for thought.
>
> Again, I'm not sure why you see features competing with OBR.
>
>
> Coming from bnd/EnRoute, in my build environment I can create different
> OBRs, and “release" to them. I can use a different OBR per workspace, which
> means that I can develop each “feature" separately, and release it to its
> own OBR. Thus, an OBR defines a “feature”.
>
No, it defines a repository, and that's fine. A feature is more than a
list of bundles.
OBR is useful when you want to install individual bundles.
For example, if you want to deploy a web application, you could write a
feature which will have a dependency on the karaf "war" feature. When you
install your feature, it will ensure the web app support is deployed
correctly.
With OBR, you'll have a dependency on the servlet api, so the servlet api
bundle will be deployed, and that's all.
Of course, if you're only interested in the simple use cases, you can use
an OBR repo and it will work.
If you want to experiment deployment based on an OBR repo + a requirement,
you could use the following file and drop it in the deploy folder:
<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0">
<resource-repository>[url to the OBR repo]</resource-repository>
<feature name="[feature name]" install="auto">
<requirement>[the requirement]</requirement>
</feature>
</features>
If that's really all you need, it should be very easy to write a small
karaf command that would do the same with the 3 parameters: a name, and obr
repo url and a requirement.
>
> What I would like to be able to do is simply push the OBR into my
> container, without having any extra layer. When I tried in the past, there
> were some bugs and it did not work out very successfully. Maybe things have
> changed since then…
>
> Using Apache ACE as an example, an OBR can be used in a way that is very
> similar to a Feature. It works extremely well in the EnRoute environment,
> and cuts down a lot of noise, IMO.
>
I haven't used ACE since a long time. It has very strong limitations
because it's based on DeploymentAdmin which do not support deploying a
bundle with multiple versions. This is a show-stopper for me.
>
> A feature descriptor supports the <resource-repository> element. The
> content of this element is an url to a OBR repository (eventually prefixed
> with json: or xml:). All features defined in the features repository will
> behave as if they have the resources defined in the OBR repository with
> <bundle dependency="true">xxx</bundle>.
>
>
> Ok, either I did not know that, or I forgot about that. I’ll take a look.
> IIRC I think this is what didn’t work for me when I tried some time ago.
>
I'd be happy to fix any bug.
>
> You can also provide a list of global repositories and configure it in
> etc/org.apache.karaf.features.cfg with the resourceRepositories key (a
> command separated list of urls).
>
>
> The problem with this approach is, unless something has changed, I have to
> restart my container each time there is a change. I would also have to
> figure out a way to push the changes to Karaf. Perhaps this is easier than
> I thought, but I did not find a good way last time I look into this.
>
Yes, that's a limited support. The reason is see problem in using this
with not much value. The first option is preferrable in Karaf imho.
>
> Also, there's absolutely no value in the OBR bundle description compared
> to a manifest. It contains the same information in a different form and is
> usually generated from the manifest. Fwiw, when a feature has a reference
> to a bundle, we do generate the OSGi Resource from the manifest directly
> without using the OBR xml description, but it's the same.
>
>
> True, but then again my understanding is that a properly curated OBR
> should provide a set of bundles, and should not change (which is why the ID
> gets updated each time there is even a minor change). The information could
> very well come from the bundles, but if the bundles don’t change and the
> index is trusted, then the pre-parsed manifest info is already in the
> index, so it’s a duplicate effort to redo the parsing. No?
>
Actually, I think it's faster to parse a manifest than to the OBR xml,
given the verbosity of the xml. Plus, it's an additional file to manage, so
it has to provide some value, else it's not worth the pain.
>
>
> Perhaps the Karaf/Maven way of thinking is very different from the bnd
> way? Or maybe there has been convergence over the past few years, but the
> tooling has not kept up? (That is what I am trying to figure out, since I
> don’t know Maven very deeply, and based on what I understand, I think I
> prefer the bnd way.)
>
Yeah, karaf tooling is definitely lacking I think.
>
>
> Cheers,
> =David
>
>
>
> On Jun 15, 2017, at 3:27 PM, Guillaume Nodet <gn...@apache.org> wrote:
>
> Again, I'm not sure why you see features competing with OBR.
> We do actually leverage OBR internally, and we can also leverage it
> externally though it's not much advertised, but it was hinted by
> Jean-Baptiste when he talked about Cave.
>
> OBR is the repository specification, so it defines a Repository
> interface. We do have multiple implementations of it in Karaf : the
> standardized XML one, a JSON based repository implementation and an in-vm
> one.
>
> A feature descriptor supports the <resource-repository> element. The
> content of this element is an url to a OBR repository (eventually prefixed
> with json: or xml:). All features defined in the features repository will
> behave as if they have the resources defined in the OBR repository with
> <bundle dependency="true">xxx</bundle>.
>
> You can also provide a list of global repositories and configure it in
> etc/org.apache.karaf.features.cfg with the resourceRepositories key (a
> command separated list of urls).
>
> Also, there's absolutely no value in the OBR bundle description compared
> to a manifest. It contains the same information in a different form and is
> usually generated from the manifest. Fwiw, when a feature has a reference
> to a bundle, we do generate the OSGi Resource from the manifest directly
> without using the OBR xml description, but it's the same.
>
> I'm really not sure what we could do to leverage OBR more...
>
>
> 2017-06-14 23:58 GMT+02:00 David Leangen <ap...@leangen.net>:
>
>>
>> Hi Guillaume,
>>
>> Thank you for this assessment.
>>
>> I agree that Features adds value. Your post explains a lot of good
>> reasons why this is so.
>>
>> My question is more about “why compete with OBR?”. Instead of embracing
>> OBR and working on top of it, it seems that Features want to replace it.
>> This is causing me to have to make a lot of choices in my deployment
>> mechanism.
>>
>> Features could be really helpful for deployment by managing OBRs,
>> configurations, and other deployment information. They could also manage
>> versioning better etc. Maybe something like what Apache ACE was trying to
>> do. However, instead of “adding” value, currently Features are completely
>> replacing OBR, which I find interesting. But I understand that there is
>> some legacy to this. Now that it works, it would take some momentum to move
>> to a more standards-based approach.
>>
>>
>> My current issue is: how can I use Features for Continuous Deployment? I
>> am having trouble with automation. That is what got me interested in the
>> idea behind the Features…
>>
>>
>> Cheers,
>> =David
>>
>>
>>
>> On Jun 15, 2017, at 6:38 AM, Guillaume Nodet <gn...@apache.org> wrote:
>>
>> So if you consider an OBR as being a collection of resources, each
>> resource having capabilities and requirements, then a feature repository is
>> an OBR repository, it's just the syntax is more concise.
>> If you want to look at what the repository look like, you can launch the
>> following command in karaf:
>> > feature:install --store resolution.json --verbose --simulate scr
>>
>> Then, look at the resolution.json file, it will contain the OBR
>> repository used by the resolver in a json format. The xml syntax would be
>> slightly different of course, and a bit more verbose too, but roughly the
>> same data.
>> I do think the features syntax is a bit more understandable.
>>
>> But you do not want to compare OBR and features. I haven't seen any OBR
>> repository used which would contain other things than just OSGi bundles.
>> Features is more a deployment artifact than an OSGi bundle, so it's more
>> to be compared with OSGi subsystems.
>>
>> With pure OBR, you can't group bundles together, you usually don't want
>> to edit such a repository file manually, so at the end, you can never
>> really hack the content. It has to be generated, and is mostly generated
>> only from a set of OSGi bundles. You can't capture all the constraints by
>> using bundles only.
>>
>> 2017-06-14 7:49 GMT+02:00 David Leangen <ap...@leangen.net>:
>>
>>>
>>> Hi!
>>>
>>> I am trying to wrap my head around the differences between an OBR and a
>>> Karaf Feature. The concepts seem to be overlapping.
>>>
>>> An OBR has an index of the contained bundles, as well as meta
>>> information, which includes requirements and capabilities. An OBR is
>>> therefore very useful for resolving bundles, and partitioning bundles into
>>> some kind of category. It can also be versioned, and can contained
>>> different versions of bundles. An OBR could potentially be used to keep
>>> snapshots of system releases. I believe that this is somewhat how Apache
>>> ACE works. (A Distribution can be rolled back by simply referring to a
>>> different OBR and allowing the system to re-resolve.) The actual bundles
>>> need to be stored somewhere. The OBR index needs to provide links to that
>>> storage.
>>>
>>> A Karaf Feature is basically an index of bundles (and configurations),
>>> too. I think that it can also be versioned, and can contain different
>>> versions of bundles. Like an OBR, it is very useful for partitioning
>>> bundles into some kind of category, so the groups of bundles can be
>>> manipulated as a single unit. Just like an OBR, the Karaf Feature also
>>> needs to provide a link to the bundles. AFAIU, resolution is done somehow
>>> in Karaf, based on the bundles available via the Features, so in the end
>>> the entire mechanism seems almost identical to what the OBR is doing.
>>>
>>>
>>> So many similarities!
>>>
>>>
>>> I understand that a Feature can include configurations, which is nice,
>>> but why have a competing non-official standard against an official
>>> standard? If configurations is the only problem, then why not build it on
>>> top of OBRs, rather than creating something completely new and different
>>> and competing?
>>>
>>> Is it to try to force lock-in to Karaf? Or am I completely missing
>>> something?
>>>
>>>
>>> Thanks for explaining! :-)
>>>
>>>
>>> Cheers,
>>> =David
>>>
>>>
>>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>>
>>
>
>
> --
> ------------------------
> Guillaume Nodet
>
>
>
--
------------------------
Guillaume Nodet
Re: Karaf Feature vs. OBR
Posted by David Leangen <ap...@leangen.net>.
Thanks Guillaume. A lot of good food for thought.
> Again, I'm not sure why you see features competing with OBR.
Coming from bnd/EnRoute, in my build environment I can create different OBRs, and “release" to them. I can use a different OBR per workspace, which means that I can develop each “feature" separately, and release it to its own OBR. Thus, an OBR defines a “feature”.
What I would like to be able to do is simply push the OBR into my container, without having any extra layer. When I tried in the past, there were some bugs and it did not work out very successfully. Maybe things have changed since then…
Using Apache ACE as an example, an OBR can be used in a way that is very similar to a Feature. It works extremely well in the EnRoute environment, and cuts down a lot of noise, IMO.
> A feature descriptor supports the <resource-repository> element. The content of this element is an url to a OBR repository (eventually prefixed with json: or xml:). All features defined in the features repository will behave as if they have the resources defined in the OBR repository with <bundle dependency="true">xxx</bundle>.
Ok, either I did not know that, or I forgot about that. I’ll take a look. IIRC I think this is what didn’t work for me when I tried some time ago.
> You can also provide a list of global repositories and configure it in etc/org.apache.karaf.features.cfg with the resourceRepositories key (a command separated list of urls).
The problem with this approach is, unless something has changed, I have to restart my container each time there is a change. I would also have to figure out a way to push the changes to Karaf. Perhaps this is easier than I thought, but I did not find a good way last time I look into this.
> Also, there's absolutely no value in the OBR bundle description compared to a manifest. It contains the same information in a different form and is usually generated from the manifest. Fwiw, when a feature has a reference to a bundle, we do generate the OSGi Resource from the manifest directly without using the OBR xml description, but it's the same.
True, but then again my understanding is that a properly curated OBR should provide a set of bundles, and should not change (which is why the ID gets updated each time there is even a minor change). The information could very well come from the bundles, but if the bundles don’t change and the index is trusted, then the pre-parsed manifest info is already in the index, so it’s a duplicate effort to redo the parsing. No?
Perhaps the Karaf/Maven way of thinking is very different from the bnd way? Or maybe there has been convergence over the past few years, but the tooling has not kept up? (That is what I am trying to figure out, since I don’t know Maven very deeply, and based on what I understand, I think I prefer the bnd way.)
Cheers,
=David
> On Jun 15, 2017, at 3:27 PM, Guillaume Nodet <gn...@apache.org> wrote:
>
> Again, I'm not sure why you see features competing with OBR.
> We do actually leverage OBR internally, and we can also leverage it externally though it's not much advertised, but it was hinted by Jean-Baptiste when he talked about Cave.
>
> OBR is the repository specification, so it defines a Repository interface. We do have multiple implementations of it in Karaf : the standardized XML one, a JSON based repository implementation and an in-vm one.
>
> A feature descriptor supports the <resource-repository> element. The content of this element is an url to a OBR repository (eventually prefixed with json: or xml:). All features defined in the features repository will behave as if they have the resources defined in the OBR repository with <bundle dependency="true">xxx</bundle>.
>
> You can also provide a list of global repositories and configure it in etc/org.apache.karaf.features.cfg with the resourceRepositories key (a command separated list of urls).
>
> Also, there's absolutely no value in the OBR bundle description compared to a manifest. It contains the same information in a different form and is usually generated from the manifest. Fwiw, when a feature has a reference to a bundle, we do generate the OSGi Resource from the manifest directly without using the OBR xml description, but it's the same.
>
> I'm really not sure what we could do to leverage OBR more...
>
>
> 2017-06-14 23:58 GMT+02:00 David Leangen <apache@leangen.net <ma...@leangen.net>>:
>
> Hi Guillaume,
>
> Thank you for this assessment.
>
> I agree that Features adds value. Your post explains a lot of good reasons why this is so.
>
> My question is more about “why compete with OBR?”. Instead of embracing OBR and working on top of it, it seems that Features want to replace it. This is causing me to have to make a lot of choices in my deployment mechanism.
>
> Features could be really helpful for deployment by managing OBRs, configurations, and other deployment information. They could also manage versioning better etc. Maybe something like what Apache ACE was trying to do. However, instead of “adding” value, currently Features are completely replacing OBR, which I find interesting. But I understand that there is some legacy to this. Now that it works, it would take some momentum to move to a more standards-based approach.
>
>
> My current issue is: how can I use Features for Continuous Deployment? I am having trouble with automation. That is what got me interested in the idea behind the Features…
>
>
> Cheers,
> =David
>
>
>
>> On Jun 15, 2017, at 6:38 AM, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>>
>> So if you consider an OBR as being a collection of resources, each resource having capabilities and requirements, then a feature repository is an OBR repository, it's just the syntax is more concise.
>> If you want to look at what the repository look like, you can launch the following command in karaf:
>> > feature:install --store resolution.json --verbose --simulate scr
>>
>> Then, look at the resolution.json file, it will contain the OBR repository used by the resolver in a json format. The xml syntax would be slightly different of course, and a bit more verbose too, but roughly the same data.
>> I do think the features syntax is a bit more understandable.
>>
>> But you do not want to compare OBR and features. I haven't seen any OBR repository used which would contain other things than just OSGi bundles.
>> Features is more a deployment artifact than an OSGi bundle, so it's more to be compared with OSGi subsystems.
>>
>> With pure OBR, you can't group bundles together, you usually don't want to edit such a repository file manually, so at the end, you can never really hack the content. It has to be generated, and is mostly generated only from a set of OSGi bundles. You can't capture all the constraints by using bundles only.
>>
>> 2017-06-14 7:49 GMT+02:00 David Leangen <apache@leangen.net <ma...@leangen.net>>:
>>
>> Hi!
>>
>> I am trying to wrap my head around the differences between an OBR and a Karaf Feature. The concepts seem to be overlapping.
>>
>> An OBR has an index of the contained bundles, as well as meta information, which includes requirements and capabilities. An OBR is therefore very useful for resolving bundles, and partitioning bundles into some kind of category. It can also be versioned, and can contained different versions of bundles. An OBR could potentially be used to keep snapshots of system releases. I believe that this is somewhat how Apache ACE works. (A Distribution can be rolled back by simply referring to a different OBR and allowing the system to re-resolve.) The actual bundles need to be stored somewhere. The OBR index needs to provide links to that storage.
>>
>> A Karaf Feature is basically an index of bundles (and configurations), too. I think that it can also be versioned, and can contain different versions of bundles. Like an OBR, it is very useful for partitioning bundles into some kind of category, so the groups of bundles can be manipulated as a single unit. Just like an OBR, the Karaf Feature also needs to provide a link to the bundles. AFAIU, resolution is done somehow in Karaf, based on the bundles available via the Features, so in the end the entire mechanism seems almost identical to what the OBR is doing.
>>
>>
>> So many similarities!
>>
>>
>> I understand that a Feature can include configurations, which is nice, but why have a competing non-official standard against an official standard? If configurations is the only problem, then why not build it on top of OBRs, rather than creating something completely new and different and competing?
>>
>> Is it to try to force lock-in to Karaf? Or am I completely missing something?
>>
>>
>> Thanks for explaining! :-)
>>
>>
>> Cheers,
>> =David
>>
>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>
>
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Karaf Feature vs. OBR
Posted by Guillaume Nodet <gn...@apache.org>.
Again, I'm not sure why you see features competing with OBR.
We do actually leverage OBR internally, and we can also leverage it
externally though it's not much advertised, but it was hinted by
Jean-Baptiste when he talked about Cave.
OBR is the repository specification, so it defines a Repository interface.
We do have multiple implementations of it in Karaf : the standardized XML
one, a JSON based repository implementation and an in-vm one.
A feature descriptor supports the <resource-repository> element. The
content of this element is an url to a OBR repository (eventually prefixed
with json: or xml:). All features defined in the features repository will
behave as if they have the resources defined in the OBR repository with
<bundle dependency="true">xxx</bundle>.
You can also provide a list of global repositories and configure it in
etc/org.apache.karaf.features.cfg with the resourceRepositories key (a
command separated list of urls).
Also, there's absolutely no value in the OBR bundle description compared to
a manifest. It contains the same information in a different form and is
usually generated from the manifest. Fwiw, when a feature has a reference
to a bundle, we do generate the OSGi Resource from the manifest directly
without using the OBR xml description, but it's the same.
I'm really not sure what we could do to leverage OBR more...
2017-06-14 23:58 GMT+02:00 David Leangen <ap...@leangen.net>:
>
> Hi Guillaume,
>
> Thank you for this assessment.
>
> I agree that Features adds value. Your post explains a lot of good reasons
> why this is so.
>
> My question is more about “why compete with OBR?”. Instead of embracing
> OBR and working on top of it, it seems that Features want to replace it.
> This is causing me to have to make a lot of choices in my deployment
> mechanism.
>
> Features could be really helpful for deployment by managing OBRs,
> configurations, and other deployment information. They could also manage
> versioning better etc. Maybe something like what Apache ACE was trying to
> do. However, instead of “adding” value, currently Features are completely
> replacing OBR, which I find interesting. But I understand that there is
> some legacy to this. Now that it works, it would take some momentum to move
> to a more standards-based approach.
>
>
> My current issue is: how can I use Features for Continuous Deployment? I
> am having trouble with automation. That is what got me interested in the
> idea behind the Features…
>
>
> Cheers,
> =David
>
>
>
> On Jun 15, 2017, at 6:38 AM, Guillaume Nodet <gn...@apache.org> wrote:
>
> So if you consider an OBR as being a collection of resources, each
> resource having capabilities and requirements, then a feature repository is
> an OBR repository, it's just the syntax is more concise.
> If you want to look at what the repository look like, you can launch the
> following command in karaf:
> > feature:install --store resolution.json --verbose --simulate scr
>
> Then, look at the resolution.json file, it will contain the OBR repository
> used by the resolver in a json format. The xml syntax would be slightly
> different of course, and a bit more verbose too, but roughly the same data.
> I do think the features syntax is a bit more understandable.
>
> But you do not want to compare OBR and features. I haven't seen any OBR
> repository used which would contain other things than just OSGi bundles.
> Features is more a deployment artifact than an OSGi bundle, so it's more
> to be compared with OSGi subsystems.
>
> With pure OBR, you can't group bundles together, you usually don't want to
> edit such a repository file manually, so at the end, you can never really
> hack the content. It has to be generated, and is mostly generated only
> from a set of OSGi bundles. You can't capture all the constraints by using
> bundles only.
>
> 2017-06-14 7:49 GMT+02:00 David Leangen <ap...@leangen.net>:
>
>>
>> Hi!
>>
>> I am trying to wrap my head around the differences between an OBR and a
>> Karaf Feature. The concepts seem to be overlapping.
>>
>> An OBR has an index of the contained bundles, as well as meta
>> information, which includes requirements and capabilities. An OBR is
>> therefore very useful for resolving bundles, and partitioning bundles into
>> some kind of category. It can also be versioned, and can contained
>> different versions of bundles. An OBR could potentially be used to keep
>> snapshots of system releases. I believe that this is somewhat how Apache
>> ACE works. (A Distribution can be rolled back by simply referring to a
>> different OBR and allowing the system to re-resolve.) The actual bundles
>> need to be stored somewhere. The OBR index needs to provide links to that
>> storage.
>>
>> A Karaf Feature is basically an index of bundles (and configurations),
>> too. I think that it can also be versioned, and can contain different
>> versions of bundles. Like an OBR, it is very useful for partitioning
>> bundles into some kind of category, so the groups of bundles can be
>> manipulated as a single unit. Just like an OBR, the Karaf Feature also
>> needs to provide a link to the bundles. AFAIU, resolution is done somehow
>> in Karaf, based on the bundles available via the Features, so in the end
>> the entire mechanism seems almost identical to what the OBR is doing.
>>
>>
>> So many similarities!
>>
>>
>> I understand that a Feature can include configurations, which is nice,
>> but why have a competing non-official standard against an official
>> standard? If configurations is the only problem, then why not build it on
>> top of OBRs, rather than creating something completely new and different
>> and competing?
>>
>> Is it to try to force lock-in to Karaf? Or am I completely missing
>> something?
>>
>>
>> Thanks for explaining! :-)
>>
>>
>> Cheers,
>> =David
>>
>>
>>
>
>
> --
> ------------------------
> Guillaume Nodet
>
>
>
--
------------------------
Guillaume Nodet
Re: Karaf Feature vs. OBR
Posted by David Leangen <ap...@leangen.net>.
>>>>> David Leangen <apache@leangen.net <ma...@leangen.net>>:
> My current issue is: how can I use Features for Continuous Deployment?
> I am having trouble with automation. That is what got me interested in
> the idea behind the Features…
> On Jun 17, 2017, at 10:27 AM, Castor <yg...@gmail.com> wrote:
> On Jun 16, 2017, at 3:53 AM, Steinar Bang <sb...@dod.no> wrote:
Hi Castor and Steinar,
Thanks for this info. I have not yet replied because I am still investigating, but the information you provided is very helpful.
Cheers,
=David
Re: Karaf Feature vs. OBR
Posted by Castor <yg...@gmail.com>.
"how can I use Features for Continuous Deployment? I am having trouble with
automation. That is what got me interested in the idea behind the Features…"
Well, here is my use case:
We have hundreds of customers, some in the cloud and some with out software
on-premises, and we have a lot of bundles, more than 100 and growing fast,
and i needed to know which versions every single customer is using, allow
him to update his bundles, allow me to install and uninstall from specific
customers or all of them, quite a job.
So, i created a tool, it runs as a bundle on a isolated region in our Karaf
which uses some OSGi services provided by Karaf ( FeaturesService,
BundleService, etc ) which communicates with a server i build that
administers and control every single thing happening inside karaf, install
stuff, delete stuff, debug stuff, stuffs stuff.
Seems complicated, but the feature system made it quite simple, the pipeline
works like this ( i will not describe our detailed pipeline, just the
general idea _
"A feature is developed" -> "The developer finishes it and creates a release
candidate" -> "Automatically it deploys to a QA enviroment" -> "The QA Peeps
test it" -> "If approved, a release is closed and sent to our Nexus
repository" -> "My server notifies all clients that a new version of the
bundle X is released" -> "My tool register the new feature repository with
repo-add" -> "The customer clicks install" -> "The feature is installed".
There are some more business restrictions and rules, but that's the general
idea, for us it works like a charm, i can even change .cfg files
informations from my control panel in a specific customer.
--
View this message in context: http://karaf.922171.n3.nabble.com/Karaf-Feature-vs-OBR-tp4050720p4050818.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Karaf Feature vs. OBR
Posted by David Leangen <ap...@leangen.net>.
Hi Guillaume,
Thank you for this assessment.
I agree that Features adds value. Your post explains a lot of good reasons why this is so.
My question is more about “why compete with OBR?”. Instead of embracing OBR and working on top of it, it seems that Features want to replace it. This is causing me to have to make a lot of choices in my deployment mechanism.
Features could be really helpful for deployment by managing OBRs, configurations, and other deployment information. They could also manage versioning better etc. Maybe something like what Apache ACE was trying to do. However, instead of “adding” value, currently Features are completely replacing OBR, which I find interesting. But I understand that there is some legacy to this. Now that it works, it would take some momentum to move to a more standards-based approach.
My current issue is: how can I use Features for Continuous Deployment? I am having trouble with automation. That is what got me interested in the idea behind the Features…
Cheers,
=David
> On Jun 15, 2017, at 6:38 AM, Guillaume Nodet <gn...@apache.org> wrote:
>
> So if you consider an OBR as being a collection of resources, each resource having capabilities and requirements, then a feature repository is an OBR repository, it's just the syntax is more concise.
> If you want to look at what the repository look like, you can launch the following command in karaf:
> > feature:install --store resolution.json --verbose --simulate scr
>
> Then, look at the resolution.json file, it will contain the OBR repository used by the resolver in a json format. The xml syntax would be slightly different of course, and a bit more verbose too, but roughly the same data.
> I do think the features syntax is a bit more understandable.
>
> But you do not want to compare OBR and features. I haven't seen any OBR repository used which would contain other things than just OSGi bundles.
> Features is more a deployment artifact than an OSGi bundle, so it's more to be compared with OSGi subsystems.
>
> With pure OBR, you can't group bundles together, you usually don't want to edit such a repository file manually, so at the end, you can never really hack the content. It has to be generated, and is mostly generated only from a set of OSGi bundles. You can't capture all the constraints by using bundles only.
>
> 2017-06-14 7:49 GMT+02:00 David Leangen <apache@leangen.net <ma...@leangen.net>>:
>
> Hi!
>
> I am trying to wrap my head around the differences between an OBR and a Karaf Feature. The concepts seem to be overlapping.
>
> An OBR has an index of the contained bundles, as well as meta information, which includes requirements and capabilities. An OBR is therefore very useful for resolving bundles, and partitioning bundles into some kind of category. It can also be versioned, and can contained different versions of bundles. An OBR could potentially be used to keep snapshots of system releases. I believe that this is somewhat how Apache ACE works. (A Distribution can be rolled back by simply referring to a different OBR and allowing the system to re-resolve.) The actual bundles need to be stored somewhere. The OBR index needs to provide links to that storage.
>
> A Karaf Feature is basically an index of bundles (and configurations), too. I think that it can also be versioned, and can contain different versions of bundles. Like an OBR, it is very useful for partitioning bundles into some kind of category, so the groups of bundles can be manipulated as a single unit. Just like an OBR, the Karaf Feature also needs to provide a link to the bundles. AFAIU, resolution is done somehow in Karaf, based on the bundles available via the Features, so in the end the entire mechanism seems almost identical to what the OBR is doing.
>
>
> So many similarities!
>
>
> I understand that a Feature can include configurations, which is nice, but why have a competing non-official standard against an official standard? If configurations is the only problem, then why not build it on top of OBRs, rather than creating something completely new and different and competing?
>
> Is it to try to force lock-in to Karaf? Or am I completely missing something?
>
>
> Thanks for explaining! :-)
>
>
> Cheers,
> =David
>
>
>
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Karaf Feature vs. OBR
Posted by Guillaume Nodet <gn...@apache.org>.
So if you consider an OBR as being a collection of resources, each resource
having capabilities and requirements, then a feature repository is an OBR
repository, it's just the syntax is more concise.
If you want to look at what the repository look like, you can launch the
following command in karaf:
> feature:install --store resolution.json --verbose --simulate scr
Then, look at the resolution.json file, it will contain the OBR repository
used by the resolver in a json format. The xml syntax would be slightly
different of course, and a bit more verbose too, but roughly the same data.
I do think the features syntax is a bit more understandable.
But you do not want to compare OBR and features. I haven't seen any OBR
repository used which would contain other things than just OSGi bundles.
Features is more a deployment artifact than an OSGi bundle, so it's more to
be compared with OSGi subsystems.
With pure OBR, you can't group bundles together, you usually don't want to
edit such a repository file manually, so at the end, you can never really
hack the content. It has to be generated, and is mostly generated only
from a set of OSGi bundles. You can't capture all the constraints by using
bundles only.
2017-06-14 7:49 GMT+02:00 David Leangen <ap...@leangen.net>:
>
> Hi!
>
> I am trying to wrap my head around the differences between an OBR and a
> Karaf Feature. The concepts seem to be overlapping.
>
> An OBR has an index of the contained bundles, as well as meta information,
> which includes requirements and capabilities. An OBR is therefore very
> useful for resolving bundles, and partitioning bundles into some kind of
> category. It can also be versioned, and can contained different versions of
> bundles. An OBR could potentially be used to keep snapshots of system
> releases. I believe that this is somewhat how Apache ACE works. (A
> Distribution can be rolled back by simply referring to a different OBR and
> allowing the system to re-resolve.) The actual bundles need to be stored
> somewhere. The OBR index needs to provide links to that storage.
>
> A Karaf Feature is basically an index of bundles (and configurations),
> too. I think that it can also be versioned, and can contain different
> versions of bundles. Like an OBR, it is very useful for partitioning
> bundles into some kind of category, so the groups of bundles can be
> manipulated as a single unit. Just like an OBR, the Karaf Feature also
> needs to provide a link to the bundles. AFAIU, resolution is done somehow
> in Karaf, based on the bundles available via the Features, so in the end
> the entire mechanism seems almost identical to what the OBR is doing.
>
>
> So many similarities!
>
>
> I understand that a Feature can include configurations, which is nice, but
> why have a competing non-official standard against an official standard? If
> configurations is the only problem, then why not build it on top of OBRs,
> rather than creating something completely new and different and competing?
>
> Is it to try to force lock-in to Karaf? Or am I completely missing
> something?
>
>
> Thanks for explaining! :-)
>
>
> Cheers,
> =David
>
>
>
--
------------------------
Guillaume Nodet