Re: Bndtools & Karaf : the right way

The point is that bndtools can generate resources descriptor, not features XML. That's why, in the way of generate "Karaf" applications directly in bndtools, it would be easier if Karaf feature can be described as resources, instead of XML. @David, correct me if I'm wrong ;) Regards JB On

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.

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

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

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

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

Karaf Maven Plugin

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

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

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

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

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

Karaf 4.0.3 : Features resolution is not consistent ?

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

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

Re: Karaf 4.0.3 & JPA

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

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

Re: Bndtools & Karaf : the right way

>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

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

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 ?

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

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

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

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,

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

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,

Re: Karaf Maven Plugin

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

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

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

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

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

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

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

Re: Bndtools & Karaf : the right way

> Anyway, once I'm given a repository and a set of bundles to look at, i'm > willing to look at it. Cool! Thank you very much! I will work on that as soon as I can. :-) Cheers, =David