Re: Karaf Feature vs. OBR

> Steinar Bang : > Steinar Bang : > [snip!] >> So, no success yet at totally automating the deployment from a >> travis-ci build. >> I still need to to "bundle:update" from the karaf console on each bundle >> I want updated after a new snapshot has been added. > The still-in-flux REST A

Re: Karaf Feature vs. OBR

> Steinar Bang : [snip!] > So, no success yet at totally automating the deployment from a > travis-ci build. > I still need to to "bundle:update" from the karaf console on each bundle > I want updated after a new snapshot has been added. The still-in-flux REST API of the webconsole offers a

Re: Karaf Feature vs. OBR

> Steinar Bang : > Guillaume Nodet : >> Fwiw, bundle:watch is very specific and only check the local repository, so >> it won't work if you upload a new snapshot on a remote repository. > I was sort of hoping it would work for a different maven repo in the > local file system, which is wh

Re: Karaf Feature vs. OBR

> Guillaume Nodet : > Fwiw, bundle:watch is very specific and only check the local repository, so > it won't work if you upload a new snapshot on a remote repository. I was sort of hoping it would work for a different maven repo in the local file system, which is what I currently have.

Re: Karaf Feature vs. OBR

Fwiw, bundle:watch is very specific and only check the local repository, so it won't work if you upload a new snapshot on a remote repository. 2017-08-31 20:44 GMT+02:00 Steinar Bang : > > Steinar Bang : > > Steinar Bang : > > Jean-Baptiste Onofré : > > >>> By the way, I'm adding "dep

Re: Karaf Feature vs. OBR

> Steinar Bang : > Steinar Bang : > Jean-Baptiste Onofré : >>> By the way, I'm adding "deployment tooling" in Cave right now >>> (allowing to explode a kar, create meta feature assembling existing >>> features, ...). >> Interesting! Will study! >> https://karaf.apache.org/manual/cave

Re: Making karaf update snapshots from remote repositories Was: Karaf Feature vs. OBR

To summarize my experiences so far: 1. I have a travis ci build that does maven snapshot deploys using ftp to a directory on the same server where karaf is running. 2. I serve the maven repository area out with HTTP and HTTPS using nginx. 3. I added the maven repository served out by

Re: Making karaf update snapshots from remote repositories Was: Karaf Feature vs. OBR

> Steinar Bang : > Steinar Bang : > [snip!] >> But the conclusion is that I'm pretty sure neither bundle:watch nor >> bundle:update works for watching a remote repository, or update a >> bundle installed from a remote repository. > (But I will be very happy to be proved wrong...) The bu

Re: Making karaf update snapshots from remote repositories Was: Karaf Feature vs. OBR

> Steinar Bang : [snip!] > But the conclusion is that I'm pretty sure neither bundle:watch nor > bundle:update works for watching a remote repository, or update a > bundle installed from a remote repository. (But I will be very happy to be proved wrong...)

Re: Making karaf update snapshots from remote repositories Was: Karaf Feature vs. OBR

> Steinar Bang : [snip!] > But as far as I can tell from the HTTP server access log, nothing is > polling maven.bang.priv.no. As far as I can tell from the source code of karaf 4.1.2[1][2], bundle:watch only works for files in the local repository. The bundle:update command also looks like it

Making karaf update snapshots from remote repositories Was: Karaf Feature vs. OBR

> Steinar Bang : > Now I've done it differently (...and perhaps more correctly...?): > 1. I've installed karaf-4.1.2 on a debian 9 "squeeze" system, using the > debian package created by this script: > https://github.com/steinarb/karaf-deb-packaging > The .deb package creates the us

Re: Karaf Feature vs. OBR

> Steinar Bang : > Jean-Baptiste Onofré : >> You can change the update global policy in etc/org.ops4j.pax.url.mvn.cfg. > Ok, on karaf 4.1.2, I've now set the global update policy, and added a > remote repo that contains snapshots: Now I've done it differently (...and perhaps more correct

Re: Karaf Feature vs. OBR

> Jean-Baptiste Onofré : > You can change the update global policy in etc/org.ops4j.pax.url.mvn.cfg. Ok, on karaf 4.1.2, I've now set the global update policy, and added a remote repo that contains snapshots: *** org.ops4j.pax.url.mvn.cfg 2017/08/18 13:58:10 1.1 --- org.ops4j.pax.url.m

Re: Karaf Feature vs. OBR

> David Leangen mailto:apa...@leangen.net>>: > My current issue is: how can I use Features for Continuous Deployment? > I am having trouble with automation. That is what got me interested in > the idea behind the Features… > On Jun 17, 2017, at 10:27 AM, Castor wrote: > On Jun 16, 2017, at

Re: Karaf Feature vs. OBR

ot; -> "The customer clicks install" -> "The feature is installed". There are some more business restrictions and rules, but that's the general idea, for us it works like a charm, i can even change .cfg files informations from my control panel in a specific customer.

Re: Karaf Feature vs. OBR

> Steinar Bang : > Jean-Baptiste Onofré : >> By the way, I'm adding "deployment tooling" in Cave right now >> (allowing to explode a kar, create meta feature assembling existing >> features, ...). > Interesting! Will study! > https://karaf.apache.org/manual/cave/latest-4/ So now I see

Re: Karaf Feature vs. OBR

You can change the update global policy in etc/org.ops4j.pax.url.mvn.cfg. Regards JB On 06/15/2017 10:06 PM, Steinar Bang wrote: Jean-Baptiste Onofré : did you try the global update policy to always to get the new SNAPSHOT from remote repo ? No, I thought listening for SNAPSHOTS was only p

Re: Karaf Feature vs. OBR

Hi Steiner, Thanks for this information. > On Jun 16, 2017, at 3:53 AM, Steinar Bang wrote: > > It doesn't involve features, except for the installation, but I do this: > 1. Use maven to build the bundles (and the features) > 2. Use a -SNAPSHOT version I’ll look into this approach. There are

Re: Karaf Feature vs. OBR

> Jean-Baptiste Onofré : > did you try the global update policy to always to get the new SNAPSHOT > from remote repo ? No, I thought listening for SNAPSHOTS was only possible on a local repo... at least I thought so up until now...:-) That would simplify deploy (much simpler than my proposed

Re: Karaf Feature vs. OBR

Hi Christian, >> I don’t know. I think I rather like the idea of the curated repositories >> that I know won’t shift over time. > You need both. During active development you want to use the newest > dependency .. at least for your own artifacts .. sometimes also for remote > ones. Then once

Re: Karaf Feature vs. OBR

Hi, did you try the global update policy to always to get the new SNAPSHOT from remote repo ? By the way, I'm adding "deployment tooling" in Cave right now (allowing to explode a kar, create meta feature assembling existing features, ...). Regards JB On 06/15/2017 08:53 PM, Steinar Bang wr

Re: Karaf Feature vs. OBR

> David Leangen : > My current issue is: how can I use Features for Continuous Deployment? > I am having trouble with automation. That is what got me interested in > the idea behind the Features… It doesn't involve features, except for the installation, but I do this: 1. Use maven to build t

Re: Karaf Feature vs. OBR

You need both. During active development you want to use the newest dependency .. at least for your own artifacts .. sometimes also for remote ones. Then once you do a release you of course want it to be completely static and not change over time. Christian 2017-06-15 13:12 GMT+02:00 David Leange

Re: Karaf Feature vs. OBR

Hi Christian, I don’t know. I think I rather like the idea of the curated repositories that I know won’t shift over time. I can package up a small OBR (with URLs related to the index file) and deploy it somewhere. I can have very fine grained management of my “sets” (I’ll refrain from calling

Re: Karaf Feature vs. OBR

Hi Guillaume, Ok, that gives me a lot to chew on for now. I’ll give it a good try before I make any more speculative comments. :-) Cheers, =David > On Jun 15, 2017, at 5:23 PM, Guillaume Nodet wrote: > > > > 2017-06-15 9:00 GMT+02:00 David Leangen >: > > Than

Re: Karaf Feature vs. OBR

2017-06-15 9:00 GMT+02:00 David Leangen : > > Thanks Guillaume. A lot of good food for thought. > > Again, I'm not sure why you see features competing with OBR. > > > Coming from bnd/EnRoute, in my build environment I can create different > OBRs, and “release" to them. I can use a different OBR pe

Re: Karaf Feature vs. OBR

Without mvn urls you can either use file urls or http urls. Both suck in some important regards: A file url requires that the refered jar resides near the OBR. Today most people work with maven repos. So a natural place for an artifact is the local maven repository. It is difficult to point a file

Re: Karaf Feature vs. OBR

It's what I said: for me there's interaction not competition. Again, we fully support OBR as resource repos in etc/org.apache.karaf.features.cfg. Regards JB On 06/15/2017 08:27 AM, Guillaume Nodet wrote: Again, I'm not sure why you see features competing with OBR. We do actually leverage OBR

Re: Karaf Feature vs. OBR

Thanks Guillaume. A lot of good food for thought. > Again, I'm not sure why you see features competing with OBR. Coming from bnd/EnRoute, in my build environment I can create different OBRs, and “release" to them. I can use a different OBR per workspace, which means that I can develop each “f

Re: Karaf Feature vs. OBR

Hi Christian, Thanks for this information. > There is one big downside to OBR unfortunately. Inside OBR the content of > bundles needs to be refered as a url. While karaf can work with mvn urls > other systems like bndtools can not. Now the problem is that you can not > populate an OBR well w

Re: Karaf Feature vs. OBR

Again, I'm not sure why you see features competing with OBR. We do actually leverage OBR internally, and we can also leverage it externally though it's not much advertised, but it was hinted by Jean-Baptiste when he talked about Cave. OBR is the repository specification, so it defines a Repository

Re: Karaf Feature vs. OBR

There is one big downside to OBR unfortunately. Inside OBR the content of bundles needs to be refered as a url. While karaf can work with mvn urls other systems like bndtools can not. Now the problem is that you can not populate an OBR well without maven urls if your artifacts reside in maven and y

Re: Karaf Feature vs. OBR

Hi Guillaume, Thank you for this assessment. I agree that Features adds value. Your post explains a lot of good reasons why this is so. My question is more about “why compete with OBR?”. Instead of embracing OBR and working on top of it, it seems that Features want to replace it. This is cau

Re: Karaf Feature vs. OBR

So if you consider an OBR as being a collection of resources, each resource having capabilities and requirements, then a feature repository is an OBR repository, it's just the syntax is more concise. If you want to look at what the repository look like, you can launch the following command in karaf

Re: Karaf Feature vs. OBR

I just did a Google search for apache cave nexus to see if anybody provided a comparison, and this is what I found: https://books.google.co.jp/books?id=JC3QD47hu24C&pg=PA280&lpg=PA280&dq=apache+cave+vs+nexus&source=bl&ots=zyJRNO8SlK&sig=qlaz61q4d7s8PbrYFEZnnQP-tlc&hl=en&sa=X&ved=0ahUKEwjphJXJ

Re: Karaf Feature vs. OBR

Thank you JB and Christian, I think that about answers my question. Right now I don’t have time to actually invest in doing anything about it, but I was just curious. :-) Cheers, =David > On Jun 15, 2017, at 1:49 AM, Jean-Baptiste Onofré wrote: > > And anyway, Karaf Features can leverage O

Re: Karaf Feature vs. OBR

M To: user@karaf.apache.org Subject: Re: Karaf Feature vs. OBR And anyway, Karaf Features can leverage OBR (directly or via Cave). Karaf can load OBR repos in org.apache.karaf.features.cfg and use it directly. Regards JB On 06/14/2017 06:46 PM, Christian Schneider wrote: Hi David, I think the reas

RE: Karaf Feature vs. OBR

When we say "OBR" are we referring to the OSGi Subsystem spec? Scott -Original Message- From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Sent: Wednesday, June 14, 2017 11:49 AM To: user@karaf.apache.org Subject: Re: Karaf Feature vs. OBR And anyway, Karaf Features can le

Re: Karaf Feature vs. OBR

And anyway, Karaf Features can leverage OBR (directly or via Cave). Karaf can load OBR repos in org.apache.karaf.features.cfg and use it directly. Regards JB On 06/14/2017 06:46 PM, Christian Schneider wrote: Hi David, I think the reason is more that features in karaf used to work a lot simpl

Re: Karaf Feature vs. OBR

Hi David, I think the reason is more that features in karaf used to work a lot simpler in the start. They were simply a list of bundles to install. Over time features got more and more abilities. So it is less to lock in people and more simply a history matter. Since karaf 4 features use the feli

Karaf Feature vs. OBR

Hi! I am trying to wrap my head around the differences between an OBR and a Karaf Feature. The concepts seem to be overlapping. An OBR has an index of the contained bundles, as well as meta information, which includes requirements and capabilities. An OBR is therefore very useful for resolvin