date:20151130

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

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

Regards
JB

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

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

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

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

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

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

Regards
JB

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

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

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

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

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

 Looks nice!

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

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

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

 Should I file a JIRA issue for this?

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

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

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

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

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

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

 Try with feature:requirement-add

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

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

 Cheers,
 =David

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

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

Re: Bndtools & Karaf : the right way

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

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

Cheers,
Guillaume

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

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

Re: Karaf Maven Plugin


Hi Luca,

The assembly goal should.

Regards
JB

On 11/30/2015 10:56 AM, lb wrote:

Hi all,

I'm working to complete my gradle-karaf-plugin
(https://github.com/lburgazzoli/gradle-karaf-features-plugin) and I
found that the karaf-maven-plugin does not automatically include the
project in which it has been used.

As example I've created a project like
https://gist.github.com/lburgazzoli/3e7dfd0cd959dc854e62 and the result
features file contains the dependencies but not the project itself
(mvn:com.github.lburgazzoli/gradle-karaf-features-plugin:1.0.0-SNAPSHOT), is
that expected ?

Regards,
Luca


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

Re: Bndtools & Karaf : the right way

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

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

Am i understanding things correctly ?


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

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

Re: Bndtools & Karaf : the right way

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

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

can express most of the things a feature can express.

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

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

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

business cases though.

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

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

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

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

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

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

Christian

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

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

Regards
JB

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

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

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

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

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

Looks nice!

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

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

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

Should I file a JIRA issue for this?

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

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

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

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

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

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

Cheers,
=David

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

Open Source Architect

Re: Bndtools & Karaf : the right way

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

xml:url-to-the-repository-xml

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

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

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

Karaf Maven Plugin

2015-11-30 Thread lb

Hi all,

I'm working to complete my gradle-karaf-plugin (
https://github.com/lburgazzoli/gradle-karaf-features-plugin) and I found
that the karaf-maven-plugin does not automatically include the project in
which it has been used.

As example I've created a project like
https://gist.github.com/lburgazzoli/3e7dfd0cd959dc854e62 and the result
features file contains the dependencies but not the project itself
(mvn:com.github.lburgazzoli/gradle-karaf-features-plugin:1.0.0-SNAPSHOT),
is that expected ?

Regards,
Luca

Re: Bndtools & Karaf : the right way

Yes, it's what I understood too.

Regards
JB

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

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

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

Am i understanding things correctly ?

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

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

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

Regards
JB

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

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

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

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

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

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

 Regards
 JB

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

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

 >

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

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

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

  Looks nice!

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

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

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

  Should I file a JIRA issue for this?

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

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

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

Re: Karaf 4.0.3 & JPA


No idea why the namespace handler does not seem to be present.

You can look through the bundles with la -s and check if the transaction 
blueprint 2.0.0 bundle is present.
You can then do bundle:service -p  to see which services it offers. 
It should offer the correct blueprint namespace handler.


If just the EntityManager is missing then maybe the DataSource is not 
present or the persistence unit bundle is not correctly identified.
You should see in the log if a persistence unit is found in a bundle and 
what it is waiting for.


Christian

Am 30.11.2015 um 18:23 schrieb Jason Reilly:

Thanks Christian,

I will try repackaging openjpa.

Switching gears a little, I have a couple of branches where I am 
flushing out these Karaf4/JPA woes.  One branch uses openjpa & another 
uses eclipselink.  Switching over to the eclipselink branch, I have 
the following configuration message in the karaf.log:


2015-11-30 11:54:56,746 | INFO  | rint Extender: 3 | 
BlueprintContainerImpl   | 39 - 
org.apache.aries.blueprint.core - 1.4.5 | Bundle 
hearsay-dao-jpa/0.0.46.SNAPSHOT is waiting for namespace handlers 
[http://aries.apache.org/xmlns/transactions/v2.0.0]


2015-11-30 11:54:56,779 | INFO  | rint Extender: 1 | 
BlueprintContainerImpl   | 39 - 
org.apache.aries.blueprint.core - 1.4.5 | Bundle 
hearsay-dao-jpa/0.0.46.SNAPSHOT is waiting for dependencies 
[(&(osgi.unit.name=hearsay)(objectClass=javax.persistence.EntityManager))]



This branch more closely resembles the 
KarafTutorial/tasklist-blueprint-cdi project.  Here are the details...


From the custom distro pom.xml file's bootFeatures:

pax-cdi

jdbc

transaction

jpa

eclipselink

hearsay-commons




From the BaseDAO class:

@PersistenceContext(unitName = "hearsay")

private EntityManager em;


From the blueprint.xml file:

http://www.osgi.org/xmlns/blueprint/v1.0.0; 
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0;


  xmlns:tx="http://aries.apache.org/xmlns/transactions/v2.0.0; 
xmlns:jpa="http://aries.apache.org/xmlns/jpa/v2.0.0;>


  

  

  interface="org.renci.hearsay.dao.AlignmentDAO" />


  class="org.renci.hearsay.dao.jpa.AlignmentDAOImpl" 
ext:field-injection="true" />





As with the openjpa branch, all the bundles are active upon bootup, 
but when I install the "hearsay-dao" feature, the dao impl bundle is 
in a graceperiod state.  When I rollback the transaction namespace in 
the blueprint.xml file to 1.2.0 & use 'enable-annotations' instead of 
'enable', I get only the following message in the karaf.log:


2015-11-30 12:20:48,312 | INFO  | pool-64-thread-1 | 
BlueprintContainerImpl   | 39 - 
org.apache.aries.blueprint.core - 1.4.5 | Bundle 
hearsay-dao-jpa/0.0.46.SNAPSHOT is waiting for dependencies 
[(&(osgi.unit.name=hearsay)(objectClass=javax.persistence.EntityManager))]



Do you have suggestions for this scenario?

Thanks,
Jason

Re: Bndtools & Karaf : the right way

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

For me the core of maven is the maven repository.

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


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


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


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

do the mirroring, caching, security checks, license checks

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


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


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


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


Christian



On 30.11.2015 13:17, David Leangen wrote:

Hi,


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


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

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

Just my 2yen.

Cheers,
=David





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

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

Re: Bndtools & Karaf : the right way


One or another "alone" is not good.

Supporting both makes sense.

Regards
JB

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


Hi,


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



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

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

Just my 2yen.

Cheers,
=David




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

Karaf 4.0.3 : Features resolution is not consistent ?

2015-11-30 Thread j3rem1e

Hello,

I am playing with Karaf 4.0.3, and i have a strange behavior with the
feature resolver. I define a feature like this :


  spring
  spring-dm


When i start a new container (without the data folder), randomly, Karaf
install Spring 3.1.4 and Spring 3.2.14. On my machine, this happens really
often, and seem related to multithreading issues (when my machine slow down,
this happen every times). I have actived the traces on debug level, but i
haven't seen anything related to the resolution process. 

it's maybe related to this discution :
http://karaf.922171.n3.nabble.com/KAR-deployment-in-Karaf-4-0-3-fails-with-varying-errors-td4043649.html

Thanks for your help!





--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-4-0-3-Features-resolution-is-not-consistent-tp4043910.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Karaf 4.0.3 & JPA


On 30.11.2015 16:13, Jason Reilly wrote:

Thanks Christian,



Then in the pom.xml for building the custom distribution, I have the 
following relevant bootFeatures:


aries-blueprint

cxf

jdbc

transaction-api/1.1.0
This is wrong. You need to install the "transaction" feature. This is 
just the API.
Also for transaction you do not need to specify a version. The feature 
will install the old and the new transaction blueprint bundle.




jpa/1.0.4
Also not sure about this one. As you use the annotations there you could 
as well install the "jpa" feature which will give you the new 2.x version.


openjpa/${openjpa.version}



Christian

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

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

Re: Karaf 4.0.3 & JPA

2015-11-30 Thread Jason Reilly

FWIW, I rebundled OpenJPA with the 
javax.transaction/javax.transaction-api/1.2 dependency & I am now able 
to successfully connect to the database.


Thanks again,
Jason


On 11/30/2015 10:56 AM, Christian Schneider wrote:
Ah .. sorry forgot that you use openjpa. This might be difficult as 
openjpa is incompatible to jta 1.2 which the transaction.blueprint 
2.0.0 requires.
In this case you will probably need to create your own transaction 
feature that skips the 2.0.0 version and only relies on jta 1.1.


I guess because of openjpa karaf installed jta 1.1 and 1.2. 
Unfortunately it does not work to install both.


Another option would be to rebundle openjpa as in fact it is 
compatible to jta 1.2 and only the import package version range is too 
small. As the openjpa guys have still not fixed this
I wonder if we should even do the rebundling at karaf or servicemix. 
On the other hand I still hope that they fix this.


Christian

On 30.11.2015 16:47, Jason Reilly wrote:
I gave that a whirl...specifically, I changed the bootFeatures to the 
following:


jdbc

transaction

jpa

openjpa/${openjpa.version}

hearsay-commons




Upon startup of the custom distro, I see the following from a list 
command:


151 | Resolved |  80 | 2.4.0  | OpenJPA Aggregate Jar


There is an exception in the karaf.log:

org.apache.karaf.features.internal.util.MultiException: Error 
restarting bundles


at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:844)[7:org.apache.karaf.features.core:4.0.3]


at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1079)[7:org.apache.karaf.features.core:4.0.3]


at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:975)[7:org.apache.karaf.features.core:4.0.3]


at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_45]


at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_45]


at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_45]


at java.lang.Thread.run(Thread.java:745)[:1.8.0_45]

Caused by: org.osgi.framework.BundleException: Activator start error 
in bundle org.apache.openjpa [151].


at 
org.apache.felix.framework.Felix.activateBundle(Felix.java:2276)[org.apache.felix.framework-5.4.0.jar:]


at 
org.apache.felix.framework.Felix.startBundle(Felix.java:2144)[org.apache.felix.framework-5.4.0.jar:]


at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]


at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:]


at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1189)[7:org.apache.karaf.features.core:4.0.3]


at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:836)[7:org.apache.karaf.features.core:4.0.3]


... 6 more

Caused by: java.lang.NoClassDefFoundError: 
javax/transaction/SystemException


at 
org.apache.openjpa.persistence.osgi.PersistenceActivator.start(PersistenceActivator.java:61)


at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)


at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226)

... 11 more

Caused by: java.lang.ClassNotFoundException: 
javax.transaction.SystemException not found by org.apache.openjpa [151]


at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)[org.apache.felix.framework-5.4.0.jar:]


at 
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]


at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)[org.apache.felix.framework-5.4.0.jar:]


at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_45]


However, the transaction packages are visible:

karaf@root()> exports | grep javax.transaction

javax.transaction.xa | 0.0.0| 0   | 
org.apache.felix.framework


javax.transaction.xa | 1.1.0| 119 | 
org.apache.geronimo.specs.geronimo-jta_1.1_spec


javax.transaction.xa | 1.2.0| 30  | javax.transaction-api

javax.transaction | 0.0.0| 0   | org.apache.felix.framework

javax.transaction | 1.1.0| 119 | 
org.apache.geronimo.specs.geronimo-jta_1.1_spec


javax.transaction | 1.2.0| 30  | javax.transaction-api


Regards,
Jason

On 11/30/2015 10:31 AM, Christian Schneider wrote:

On 30.11.2015 16:13, Jason Reilly wrote:

Thanks Christian,



Then in the pom.xml for building the custom distribution, I have 
the following relevant bootFeatures:


aries-blueprint

cxf

jdbc

transaction-api/1.1.0
This is wrong. You

Re: Karaf 4.0.3 & JPA


This all looks pretty good.

One thing I just found recently is that you need to separate  the 
persistence unit bundle and the bundle injecting the EntityManager.
It will not work if both are in the same bundle at least not with 
blueprint - with ds this seems to work.


Christian

Am 30.11.2015 um 19:07 schrieb Jason Reilly:



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

No idea why the namespace handler does not seem to be present.

You can look through the bundles with la -s and check if the 
transaction blueprint 2.0.0 bundle is present.


karaf@root()> la -s | grep transaction

 31 | Active   |  80 | 1.2 | javax.transaction-api

 59 | Active   |  80 | 1.1.1   | 
org.apache.aries.transaction.blueprint


 60 | Active   |  80 | 2.0.0   | 
org.apache.aries.transaction.blueprint


 61 | Active   |  80 | 1.3.0   | 
org.apache.aries.transaction.manager



You can then do bundle:service -p  to see which services it 
offers. It should offer the correct blueprint namespace handler.


karaf@root()> bundle:services -p 60

Apache Aries Transaction Blueprint (60) provides:

-

objectClass = [org.osgi.service.blueprint.container.BlueprintContainer]

osgi.blueprint.container.symbolicname = 
org.apache.aries.transaction.blueprint


osgi.blueprint.container.version = 2.0.0

service.bundleid = 60

service.id = 201

service.scope = singleton



objectClass = [org.apache.aries.blueprint.NamespaceHandler]

osgi.service.blueprint.compname = nsHandler

osgi.service.blueprint.namespace = 
http://aries.apache.org/xmlns/transactions/v2.0.0


service.bundleid = 60

service.id = 273

service.scope = bundle


That all looks good.

If just the EntityManager is missing then maybe the DataSource is not 
present or the persistence unit bundle is not correctly identified.
You should see in the log if a persistence unit is found in a bundle 
and what it is waiting for.


I am deploying the datasource as a bundle & seems to be registered fine:

karaf@root()> service:list javax.sql.DataSource

[javax.sql.DataSource]

--

 osgi.jndi.service.name = hearsayNoJTA

 osgi.service.blueprint.compname = hearsay-ds-no-jta

 service.bundleid = 268

 service.id = 269

 service.scope = bundle

Provided by :

 Hearsay :: Datasource (268)

[javax.sql.DataSource]

--

 osgi.jndi.service.name = hearsayJTA

 osgi.service.blueprint.compname = hearsay-ds-jta

 service.bundleid = 268

 service.id = 270

 service.scope = bundle

Provided by :

 Hearsay :: Datasource (268)


The persistence.xml file has the following:

  
org.eclipse.persistence.jpa.PersistenceProvider

osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=hearsayJTA) 

osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=hearsayNoJTA) 




I think this configuration all lines up, so I am leaning towards the 
"persistence unit bundle is not correctly identified" idea. The dao 
impl bundle finally fails with the following exception:


2015-11-30 12:25:48,287 | ERROR | rint Extender: 2 | 
BlueprintContainerImpl   | 39 - 
org.apache.aries.blueprint.core - 1.4.5 | Unable to start blueprint 
container for bundle hearsay-dao-jpa/0.0.46.SNAPSHOT due to unresolved 
dependencies 
[(&(osgi.unit.name=hearsay)(objectClass=javax.persistence.EntityManager))]


java.util.concurrent.TimeoutException

at 
org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:343)[39:org.apache.aries.blueprint.core:1.4.5]


at 
org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[39:org.apache.aries.blueprint.core:1.4.5]



Is there something else I should be looking for?

Thanks,
Jason

Re: Bndtools & Karaf : the right way

2015-11-30 Thread development

 

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

David Daniel 

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

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

Re: Bndtools & Karaf : the right way




Am 01.12.2015 um 05:55 schrieb David Leangen:



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

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

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


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


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

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


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

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


Christian

Re: Bndtools & Karaf : the right way

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

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

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

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

Re: Bndtools & Karaf : the right way


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

That sounds very nice.

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

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

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

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

Sounds so to me. :-)

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

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


Cheers,
=David

Re: Bndtools & Karaf : the right way


feature:install with SymbolicName sounds good.

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


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


Regards
JB

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

I think something that might work is:

feature:install [;]

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

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

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

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

Christian

On 30.11.2015 11:51, Guillaume Nodet wrote:

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

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





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

Re: Bndtools & Karaf : the right way


Hi,

Wow! This list is really active. :-D

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

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


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

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

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

Used on my “application service” class:

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

The capability output via bnd to the Manifest:

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

[**Note:

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


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

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

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

In crappy ASCII art, it would be:

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

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

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

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

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

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


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

Cheers,
=David

Re: Bndtools & Karaf : the right way


Hi,

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


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

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

Just my 2yen.

Cheers,
=David

Re: Bndtools & Karaf : the right way

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


Regards
JB

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

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

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

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


Hi,

Wow! This list is really active. :-D

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

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


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

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

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

Used on my “application service” class:

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

The capability output via bnd to the Manifest:

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

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

[**Note:


The requirement for a feature is already formalized in karaf:

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


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

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

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

In crappy ASCII art, it would be:

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

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

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

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

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

Re: Bndtools & Karaf : the right way

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

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

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

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

Cheers,
=David

Re: Karaf Maven Plugin

2015-11-30 Thread lb

But it does it only if includeProjectArtifact is set, correct ?

On Mon, Nov 30, 2015 at 10:57 AM, Jean-Baptiste Onofré 
wrote:

> Hi Luca,
>
> The assembly goal should.
>
> Regards
> JB
>
>
> On 11/30/2015 10:56 AM, lb wrote:
>
>> Hi all,
>>
>> I'm working to complete my gradle-karaf-plugin
>> (https://github.com/lburgazzoli/gradle-karaf-features-plugin) and I
>> found that the karaf-maven-plugin does not automatically include the
>> project in which it has been used.
>>
>> As example I've created a project like
>> https://gist.github.com/lburgazzoli/3e7dfd0cd959dc854e62 and the result
>> features file contains the dependencies but not the project itself
>> (mvn:com.github.lburgazzoli/gradle-karaf-features-plugin:1.0.0-SNAPSHOT),
>> is
>> that expected ?
>>
>> Regards,
>> Luca
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Bndtools & Karaf : the right way


Gradle can work with Maven.

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



I think something that might work is:

feature:install [;]


That sounds very nice.


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

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


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

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


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


Sounds so to me. :-)


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


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


Cheers,
=David



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

Re: Bndtools & Karaf : the right way

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

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

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

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

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

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

Re: Bndtools & Karaf : the right way

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

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

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


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

Re: Bndtools & Karaf : the right way

Hi David,

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

Regards
JB

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

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

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

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

Looks nice!

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

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

Should I file a JIRA issue for this?

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

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

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

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

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

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

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

Cheers,
=David

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

Re: Bndtools & Karaf : the right way

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

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

Regards
JB

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

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

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

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

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

Looks nice!

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

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

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

Should I file a JIRA issue for this?

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

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

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

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

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

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

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

Cheers,
=David

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

Re: Bndtools & Karaf : the right way

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

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

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

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

Re: Bndtools & Karaf : the right way