Re: Karaf Feature vs. OBR

[Guillaume Nodet]

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 :

>
> 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: Does hibernate work in karaf 4.1 (it does in 4.0)?

[Achim Nierbeck]

Hi tom,

I know Karaf 4.1.1 and Hibernate works, though I don't have an OSS project
at hand to prove it.
I might sound a bit grumpy, but my gut feeling tells me the root to your
issues are those bndtools generated bundles.
I fear sometimes they do provide to much "included" when run in a Karaf
env.
If you want to have a Karaf with Hibernate running, start with a vanilla
Karaf (not minimal).
Issue the following commands:
feature:install hibernate
feature:install jpa
You'll see that most of the required bundles are already available.
For example a bundle providing Expression Language.

Just as a hint, maybe it's best to start off with a vanilla Karaf and if
you know the features are working, and you know which ones are actually
required, to go down the path of building a customized karaf.

regards, Achim




2017-06-14 20:36 GMT+02:00 :

> I've been struggling to get our code that uses Hibernate to work within
> Karaf 4.1 today.
> I have created a simple test case, which is on github:
> https://github.com/tomq42/karaf-tests-hibernate. There are a variety of
> branches, each with a different combination of hibernate and karaf. The
> branches karaf_4.0.9 and hibernate_5.3.4_karaf_4.1.1 are the most
> interesting.
>
> My test is to have a bundle with an activator, where the start method just
> does:
>
> javax.validation.Validation
> .byProvider(HibernateValidator.class)
> .providerResolver(new MyProviderResolver())
> .configure()
> .buildValidatorFactory()
> .getValidator();
>
> I write the java with bndtools in Eclipse. I then run the gradle script
> provided by bndtools to publish the resulting bundle to my local maven
> repository. I then run maven to build a feature containing the bundle, and
> then use the karaf-assembly packaging to product a karaf distribution,
> including the karaf "enterprise" feature repository, and hence its
> "hibernate-validator" feature. I then run the distribution, and it either
> says "great, created a validator", or prints a nasty stack trace.
>
> If I try this with karaf 4.1.1, I can't get it to work. It fails with
>
>   javax.validation.ValidationException: HV000183: Unable to initialize
> 'javax.el.ExpressionFactory'. Check that you have the EL dependencies on
> the classpath
>...
>   Caused by: java.lang.ClassNotFoundException: 
> com.sun.el.ExpressionFactoryImpl
> not found by org.hibernate.validator
>
>
> The thing is that I try with Karaf 4.0.9, and I *can* get it to work. Same
> code, just compiled against different versions of hibernate, so that the
> requirements match the version of karaf. In both cases, I have configured
> Eclipse/bndtools to use the same version of hibernate as that version of
> Karaf ships with.
>
> Karaf 4.0 series seems to use hibernate 5.0.3, Karaf 4.1 seems to use
> hibernate 5.3.4.
>
> From within eclipse I can run OSGi using bndtools. If I compile and run
> against Hibernate 5.0, and ensure that the glassfish.javax.el bundle is
> available at runtime, I can successfully create a validator. I can then
> build the same bundle and build my Karaf 4.0 based distribution, and the
> result runs. I can use hibernate 5.2 as well, and that works within
> bndtools (I'm not sure I would know how to make karaf use a later version
> of hibernate than the one it ships with).
>
> If I build and run against hibernate 5.3 within bndtools, I get the error
> (java.lang.ClassNotFoundException: com.sun.el.ExpressionFactoryImpl), and
> I get the same if I then build the java and build my karaf 4.1 based
> distribution. Note that in both cases I have the glassfish.javax.el
> available, so the com.sun.el classes should be available.
>
> For a while I was convinced that it was a problem with boot class
> delegation, since com.sun.* is in the org.osgi.framework.bootdelegation
> setting in the config.properties file. I wondered whether because of that
> boot class delegation, it wouldn't attempt to load the classes out of the
> bundle, and instead try to load them from the boot classloader. However the
> same is true in Karaf 4.0.9, and it works fine there. So I think that was a
> red herring.
>
> So something seems to changed within hibernate to render it incompatible
> with Karaf 4.1?
>
> So I'm out of ideas. The fact that it works in 4.0.9 suggest that
> fundamentally I'm not doing anything wrong, and that something has changed
> in hibernate to cause this to now fail.
>
> I found an old thread on this list on which Christian had posted a link to
> some test cases for Hibernate, here: https://github.com/hibernate/
> hibernate-validator/blob/master/osgi/integrationtest/
> src/test/java/org/hibernate/validator/osgi/integrationtest/
> OsgiIntegrationTest.java. I have experimented with using context class
> loaders, as per the test case, in the hope that this might fix it, but it
> doesn't seem to.
>
> Can anyone confirm whether hibernate works on 4.1.1, and if so, what I'm
> doing wrong? I'm hoping 

Re: Complex config

[dynamodan]

I found this thread because of a similar need -- I store a configuration in
yaml format for a java application that I'm "OSGi-fying".  The flat
dictionary isn't going to work for me, nor is the
`${karaf.etc}/worker-config.yaml` method going to work (it won't monitor the
worker-config.yaml for updates!).

+jbonofre, you mentioned something about an adapter:


jbonofre wrote
> What do you mean exactly ? You want to load the yaml configuration in 
> ConfigAdmin ? In that case, it's possible in an adapter.

That would be cool, but if it is even simpler, let's be format-agnostic, and
just implement and register a ManagedService.updated() function that gets
run any time the filesystem detects a change (along the lines of
java.nio.file.WatchService).  Send a null java.util.Dictionary object and
let the function sort out what changed, if anything.

Thanks in advance!



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Complex-config-tp4043584p4050746.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Karaf Feature vs. OBR

[David Leangen]

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=PA280=PA280=apache+cave+vs+nexus=bl=zyJRNO8SlK=qlaz61q4d7s8PbrYFEZnnQP-tlc=en=X=0ahUKEwjphJXJjb7UAhUES7wKHVk8BXgQ6AEILDAB#v=onepage=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  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é  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 >> >:
>>>   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

Re: Karaf Feature vs. OBR

[David Leangen]

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é  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 > >:
>>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

[Jean-Baptiste Onofré]

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:j...@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 >:


 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

RE: Karaf Feature vs. OBR

[Leschke, Scott]

When we say "OBR" are we referring to the OSGi Subsystem spec?

Scott

-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@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  >:
> 
> 
> 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

[Jean-Baptiste Onofré]

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 >:



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 



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



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

Re: Karaf Feature vs. OBR

[Christian Schneider]

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 :

>
> 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


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

Re: Karaf maven plugin/wrap/slf4j problem

[tom]

> I propose to share the code and chat directly (on hangout/skype/private 
> e-mail).
Any help you can give me would be greatly appreciated.
I have many issues that I'm trying to resolve, as you can tell.

Re: Why can I not satisfy "(&(osgi.extender=osgi.component)(version>=1.3.0)(!(version>=2.0.0)))"

[Jean-Baptiste Onofré]

For sure, to validate your feature, it has to define scr as inner or dependency 
feature.


Regards
JB

On 06/14/2017 02:44 PM, t...@quarendon.net wrote:

Oddly I can no longer reproduce the issue.

I thought it might have gone away because I'd added:
scr
into my feature in the features.xml file. However I take that out again and it 
still works. Odd.

If I encounter it again, I'll reduce to a simple test case.


On 14 June 2017 at 09:45 Jean-Baptiste Onofré  wrote:


That would be great.

In the mean time, I'm testing with the karaf-samples I prepared for the dev
guide update.

Regards
JB

On 06/14/2017 10:24 AM, t...@quarendon.net wrote:

Can you share your sample project ?


I will try to put together a simple standalone test case. In fact I'll do that 
for something else as well that I can't get past.



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


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

Re: Karaf maven plugin/wrap/slf4j problem

[Jean-Baptiste Onofré]

Hi Tom,

I will take a look on your code.

You custom distribution needs the log feature providing slf4j packages, else 
wrap will need the slf4j package.


Tom, it's really hard to follow how you define your feature/custom distribution.

I propose to share the code and chat directly (on hangout/skype/private e-mail).

Regards
JB

On 06/14/2017 01:13 PM, t...@quarendon.net wrote:

I have put together a simple example of the problem I'm been encountering 
attempting to create a custom karaf distribution.

If you attempt to include a bundle such as 
org.apache.felix:org.apache.felix.http.servlet-api in a feature, you get this 
build error:

missing requirement [org.ops4j.pax.url.wrap/2.5.2] osgi.wiring.package; 
filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"

org.apache.felix.http.servlet-api has a "compile" dependency on 
org.apache.tomcat/tomcat-servlet-api/8.0.9 and this is interpreted by the karaf maven 
plugin as a dependency. Whether it should do that or not I don't know. It doesn't seem 
like it should, but that's not the issue. Having made that interpretation, it then adds a 
dependency on wrap:mvn:org.apache.tomcat/tomcat-servlet-api/8.0.9, since it isn't proper 
OSGi bundle. The build then fails with the above error.

I don't understand how to resolve this issue.

If I remove this and build karaf, in the result, I can see that wrap starts, 
and satisfies the requirement from the pax-logging bundle:
   Imported Packages
   org.slf4j,version=1.7.13 from org.ops4j.pax.logging.pax-logging-api (6)
   org.slf4j,version=1.7.7 from org.ops4j.pax.logging.pax-logging-api (6)
   org.slf4j,version=1.7.1 from org.ops4j.pax.logging.pax-logging-api (6)
   org.slf4j,version=1.6.6 from org.ops4j.pax.logging.pax-logging-api (6)
   org.slf4j,version=1.5.11 from org.ops4j.pax.logging.pax-logging-api (6)
   org.slf4j,version=1.4.3 from org.ops4j.pax.logging.pax-logging-api (6)

So I don't get why it can't be resolved during the build. Is there some dependency I need 
to add to my feature in the features.xml file? It doesn't feel like I should, as my 
feature doesn't really depend on "wrap", and I shouldn't be concerned with what 
it itself then depends on?

It feels like the dependency on tomcat-servlet-api is being added in error, but 
I could live with that if I could get the result to compile.

See code at https://github.com/tomq42/karaf-tests-1

Thanks.



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

Re: Why can I not satisfy "(&(osgi.extender=osgi.component)(version>=1.3.0)(!(version>=2.0.0)))"

[tom]

Oddly I can no longer reproduce the issue.

I thought it might have gone away because I'd added:
   scr
into my feature in the features.xml file. However I take that out again and it 
still works. Odd.

If I encounter it again, I'll reduce to a simple test case.

> On 14 June 2017 at 09:45 Jean-Baptiste Onofré  wrote:
> 
> 
> That would be great.
> 
> In the mean time, I'm testing with the karaf-samples I prepared for the dev 
> guide update.
> 
> Regards
> JB
> 
> On 06/14/2017 10:24 AM, t...@quarendon.net wrote:
> >> Can you share your sample project ?
> > 
> > I will try to put together a simple standalone test case. In fact I'll do 
> > that for something else as well that I can't get past.
> > 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Karaf maven plugin/wrap/slf4j problem

[tom]

I have put together a simple example of the problem I'm been encountering 
attempting to create a custom karaf distribution.

If you attempt to include a bundle such as 
org.apache.felix:org.apache.felix.http.servlet-api in a feature, you get this 
build error:

missing requirement [org.ops4j.pax.url.wrap/2.5.2] osgi.wiring.package; 
filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"

org.apache.felix.http.servlet-api has a "compile" dependency on 
org.apache.tomcat/tomcat-servlet-api/8.0.9 and this is interpreted by the karaf 
maven plugin as a dependency. Whether it should do that or not I don't know. It 
doesn't seem like it should, but that's not the issue. Having made that 
interpretation, it then adds a dependency on 
wrap:mvn:org.apache.tomcat/tomcat-servlet-api/8.0.9, since it isn't proper OSGi 
bundle. The build then fails with the above error.

I don't understand how to resolve this issue. 

If I remove this and build karaf, in the result, I can see that wrap starts, 
and satisfies the requirement from the pax-logging bundle:
  Imported Packages
  org.slf4j,version=1.7.13 from org.ops4j.pax.logging.pax-logging-api (6)
  org.slf4j,version=1.7.7 from org.ops4j.pax.logging.pax-logging-api (6)
  org.slf4j,version=1.7.1 from org.ops4j.pax.logging.pax-logging-api (6)
  org.slf4j,version=1.6.6 from org.ops4j.pax.logging.pax-logging-api (6)
  org.slf4j,version=1.5.11 from org.ops4j.pax.logging.pax-logging-api (6)
  org.slf4j,version=1.4.3 from org.ops4j.pax.logging.pax-logging-api (6)

So I don't get why it can't be resolved during the build. Is there some 
dependency I need to add to my feature in the features.xml file? It doesn't 
feel like I should, as my feature doesn't really depend on "wrap", and I 
shouldn't be concerned with what it itself then depends on?

It feels like the dependency on tomcat-servlet-api is being added in error, but 
I could live with that if I could get the result to compile.

See code at https://github.com/tomq42/karaf-tests-1

Thanks.

Re: Why can I not satisfy "(&(osgi.extender=osgi.component)(version>=1.3.0)(!(version>=2.0.0)))"

[Jean-Baptiste Onofré]

That would be great.

In the mean time, I'm testing with the karaf-samples I prepared for the dev 
guide update.


Regards
JB

On 06/14/2017 10:24 AM, t...@quarendon.net wrote:

Can you share your sample project ?


I will try to put together a simple standalone test case. In fact I'll do that 
for something else as well that I can't get past.



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

Re: Why can I not satisfy "(&(osgi.extender=osgi.component)(version>=1.3.0)(!(version>=2.0.0)))"

[tom]

> Can you share your sample project ?

I will try to put together a simple standalone test case. In fact I'll do that 
for something else as well that I can't get past.

Re: Why can I not satisfy "(&(osgi.extender=osgi.component)(version>=1.3.0)(!(version>=2.0.0)))"

[Achim Nierbeck]

Hi Tom,

also, how does your bnd "project" look like,
my gut feeling tells me right now, it might be because of duplicate bundles
installed via std. Karaf and bnd-tools,
may this be an issue?

regards, Achim


2017-06-14 10:08 GMT+02:00 Jean-Baptiste Onofré :

> Hi,
>
> Can you share your sample project ?
>
> Thanks,
> Regards
> JB
>
>
> On 06/14/2017 09:18 AM, t...@quarendon.net wrote:
>
>> I'm trying to build a custom karaf distribution using the maven
>> karaf-assembly packaging type.
>>
>> My latest issue is that the build fails with
>>
>> missing requirement osgi.extender; filter:="(&(osgi.extender=osgi
>> .component)(version>=1.3.0)(!(version>=2.0.0)))"
>>
>> I interpret this as meaning the bundle uses DS and therefore I need
>> apache.felix.scr.
>>
>> If I don't add my bundle in, the build works, and when I start up the
>> resulting karaf, feature:list shows that scr is installed and started.
>> "bundle:headers mvn:org.apache.felix/org.apache.felix.scr/2.0.10" shows:
>>
>> Provide-Capability =
>>  osgi.extender;uses:=org.osgi.service.component;osgi.extende
>> r=osgi.component;version:Version=1.3
>>
>> So I appear to have that capability don't I?
>>
>> So why does the build apparently fail in that way?
>>
>> My POM has:
>> 
>>  
>>  org.apache.karaf.features
>>  framework
>>  ${karafVersion}
>>  kar
>>  
>>  
>>  org.apache.karaf.features
>>  standard
>>  ${karafVersion}
>>  features
>>  xml
>> compile
>>  
>>
>> and then:
>>
>>  
>>  org.apache.karaf.tooling
>>  karaf-maven-plugin
>>  4.1.1
>>  true
>>  
>>  
>>  wrapper
>>  
>>  
>>  eventadmin
>>  
>>  
>>  standard
>>  webconsole
>>  http-whiteboard
>>  scr
>>  prereqs
>>  
>>  1.8
>>  
>>  
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Why can I not satisfy "(&(osgi.extender=osgi.component)(version>=1.3.0)(!(version>=2.0.0)))"

[tom]

I'm trying to build a custom karaf distribution using the maven karaf-assembly 
packaging type.

My latest issue is that the build fails with 

missing requirement osgi.extender; 
filter:="(&(osgi.extender=osgi.component)(version>=1.3.0)(!(version>=2.0.0)))"

I interpret this as meaning the bundle uses DS and therefore I need 
apache.felix.scr.

If I don't add my bundle in, the build works, and when I start up the resulting 
karaf, feature:list shows that scr is installed and started. "bundle:headers 
mvn:org.apache.felix/org.apache.felix.scr/2.0.10" shows:

Provide-Capability =

osgi.extender;uses:=org.osgi.service.component;osgi.extender=osgi.component;version:Version=1.3

So I appear to have that capability don't I? 

So why does the build apparently fail in that way?

My POM has:
   

org.apache.karaf.features
framework
${karafVersion}
kar


org.apache.karaf.features
standard
${karafVersion}
features
xml
compile


and then:


org.apache.karaf.tooling
karaf-maven-plugin
 4.1.1
 true


wrapper


eventadmin


standard
webconsole
http-whiteboard
scr
prereqs

1.8