I was actually thinking about Cave. I am trying to space out the addition of new components to support our usage of Karaf since I want to make sure it's understood why I want those things, like an OBR repo(I introduced Karaf for the work I'm doing) if that makes sense.
I think at this point it might be a good idea to start playing with it. Will Cave work on Karaf 4.0? Also is there any reason that someone would not want to use an OBR repository? If I wanted to use Cave and Ace, would I want to pull in Cellar (I know Cellar integrates with Ace from things I've run across)? I certainly want to take advantage of things that the Apache Karaf project provides since I really love working with it. Actually I find development overall to be much more fun using Karaf and OSGi, despite the challenges that can be encountered. Ryan On Apr 15, 2015 6:20 PM, "Jean-Baptiste Onofré" <j...@nanthrax.net> wrote: > I second Achim here: we did Cave exactly to easily provide maven and OBR > repositories server ! > > Regards > JB > > > > Sent from my Samsung device > > > -------- Original message -------- > From: Achim Nierbeck <bcanh...@googlemail.com> > Date: 16/04/2015 00:12 (GMT+01:00) > To: user@karaf.apache.org > Subject: Re: Deploying applications on Karaf > > Hi, > > regarding OBR server, you still can use the Apache Karaf Cave modules to > turn one of your Karaf instances into an OBR server ;) > > regards, Achim > > 2015-04-15 22:41 GMT+02:00 Ryan Moquin <fragility...@gmail.com>: > >> Thanks Achim. I think that adding it to your pom with aggregate features >> set on the plugin will add it to the features xml. >> >> Ah, that's right. That's what I observed and forgot that it matches what >> you guys said about feature uninstalling. >> >> I can't wait to try Karaf 4. >> >> I'll get details on it and ask the ops4j guys. >> >> I am thinking I should look into utilizing OBR with Karaf. Not sure if >> Artifactory can function as an OBR like Nexus still. >> >> Thanks! >> >> Ryan >> Hi Ryan, >> >> some comments inline >> >> regards, Achim >> >> >> 2015-04-13 0:14 GMT+02:00 Ryan Moquin <fragility...@gmail.com>: >> >>> Don't get me, features are a ton of help. :) I could maintain the >>> features myself, I just hate to have to keep two lists of dependencies. >>> The reason that the karaf maven plugin is a little tough sometimes is >>> because it's hard to make sure that you don't end up with bundles in a >>> generated feature that should come from a dependent feature without making >>> everything provided. Making most of the dependencies provided makes it >>> hard to have transitive dependencies available in project dependencies >>> because they are marked provided in the other poms. There is probably a >>> better way to handle it that I haven't figured out yet. My project is >>> growing rapidly so I am trying to leverage whatever tools I can to keep my >>> features clean and not have to spend lots of time on them. >>> >>> Have you tried to add features as dependencies to your pom. AFAIK those >> should show up as dependencies in the generated features.xml. If not we >> just found a new use-case for the maven plugin and you could open an issue >> for it ;) >> >> >>> One thing I've been wrestling with (not sure if this has been improved >>> in Karaf 4) >>> is figuring out how to upgrade features and handle undeploying >>> features.. I've played around with it but I guess I'm not sure I understand >>> the proper way to do it. Such as if you had an application deployed in an >>> environment and wanted to upgrade a feature, do you have to install the new >>> features and uninstall the old one? When I've tried to uninstall a feature >>> previously, it didn't seem like everything got removed. >>> >> Till Karaf 4, you explicitly need to uninstall transitive features >> because the features installer used to be quite dumb and therefore doesn't >> know of possible other dependencies on this feature. >> With Karaf 4 this will improve quite a bit. >> >> >>> I want want to be able to do incremental upgrades of my app but not sure >>> the best way to achieve that with features. :) I've done quite a lot of >>> research on it but haven't quite narrowed down a concrete way to do it (I >>> mean beyond manually upgrading individual bundles in the karaf console.) >>> >>> Upgrades is still an "open" field, with Karaf 4 I think it will be >> easier. >> >> >>> Our Bamboo instance has access to the internet. I think it hangs right >>> at the beginning of Pax Exam starting up. It's such a pain to deal with >>> our Bamboo EC2 instance that I haven't been able to find out why it's >>> hanging yet. >>> >> maybe post this as a question at the OPS4j list with some more details of >> the logfiles. >> >> >> >> >>> Ryan >>> On Apr 12, 2015 2:34 AM, "Achim Nierbeck" <bcanh...@googlemail.com> >>> wrote: >>> >>>> Hi Ryan, >>>> >>>> see comments inline. >>>> >>>> regards, Achim >>>> >>>> >>>> 2015-04-12 0:37 GMT+02:00 Ryan Moquin <fragility...@gmail.com>: >>>> >>>>> Thanks, Achim. I am using a custom Karaf distribution, but >>>>> maintaining deployment flexibility using features feels a little tougher >>>>> than it feels like it should be (I don't have any better ideas). >>>>> >>>> That's strange, cause features are there to make life easier not >>>> harder. Make sure you cut the features right, not to big but also not to >>>> small (like one bundle, one feature). Usually it helps to create those >>>> feature files yourself as the plugin can't estimate what your intension of >>>> this combination of bundles is. >>>> >>>> >>>>> I also have issues with my Karaf integration tests in Bamboo. >>>>> Paxexam seems to not be able to initialize properly for who knows what >>>>> reason. Another problem is that I seem to run into a lot of problems in >>>>> the tests and can't seem to find anything in the output or Karaf love that >>>>> indicate.the problem. If I run it normally in Karaf, I usually get clued >>>>> into what the issue is. >>>>> >>>> Now that could be addressed. First of all, does it work for you on your >>>> machine? Is Bamboo capable of connecting to the internet. >>>> Is maven capable of connecting to the required repositories. Do you >>>> have all dependencies defined in your POM, so the configuration section of >>>> the test does find those (combined with the depends-maven-plugin) >>>> >>>> >>>>> One last thing is that since my development shop uses MacOSx, Docker >>>>> containers have to be run in a VM which feels silly and is slow. I don't >>>>> have a choice in that manner. >>>>> >>>> Oh, I'm working with MacOSx too. I know it can be cumbersome but >>>> running 4 images in parallel can be done :-) >>>> >>>> >>>> >>>>> It would be nice if there was a way to manage feature xml files in a >>>>> way that felt more straight forward.... Maybe there is and I'm just not >>>>> aware of it. >>>>> >>>> You have the choices, use the karaf maven plugin for generation, or >>>> build those yourself. In the end it's up to how you want your application >>>> build. >>>> But maybe I miss something cause usually you have a certain set of >>>> bundles running in your application that need to run anyway. With this >>>> setup you can test your application. >>>> >>>> >>>> >>>>> On Apr 8, 2015 3:07 PM, "Achim Nierbeck" <bcanh...@googlemail.com> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> just recently for a talk with showcase I was thinking about how to >>>>>> create a CI/CD build pipeline with Karaf. Maybe some of this does help >>>>>> you.[1] >>>>>> In the end I ended up with a setup where I have a pre-configured >>>>>> Karaf (custom build) which is startable as Docker Image or can be used as >>>>>> startup tar.gz of the Pax Exam integration tests. >>>>>> Usually camel routes are more about Integration therefore the most >>>>>> use-cases need to be handled by Integration tests. In those scenarios you >>>>>> just can't rely only on the camel-core bundles therefore you need more >>>>>> features just to have your unit tests/integration tests runnable. In >>>>>> those >>>>>> scenarios I usually suggest build your own distribution on top of Karaf >>>>>> and >>>>>> use it as your base-image in the pax-exam tests. If there is more >>>>>> external >>>>>> infrastructure needed I tend to use either full-integration test systems >>>>>> or >>>>>> now a docker based test-environment which can be started via a maven goal >>>>>> as pre-intergration phase systems. >>>>>> >>>>>> regards, Achim >>>>>> >>>>>> [1] - https://github.com/ANierbeck/JavaLang-Tooling >>>>>> >>>>>> 2015-04-08 17:24 GMT+02:00 Ryan Moquin <fragility...@gmail.com>: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have another question regarding Karaf and deployments. I was >>>>>>> hoping maybe some others could chime in on how they deal with the >>>>>>> following >>>>>>> situation. >>>>>>> >>>>>>> I've been working on a fairly complex Karaf based application. I'm >>>>>>> using features heavily to allow deploying the correct resources in >>>>>>> different environments (configuration and bundles). I find it works >>>>>>> very >>>>>>> well except for a couple situations: >>>>>>> >>>>>>> 1. Unit testing. It's hard to unit test things like camel routes >>>>>>> since I have ended up basically marking all bundle dependencies as >>>>>>> provided >>>>>>> (in order to keep the created features files . So if I try to unit >>>>>>> test a >>>>>>> Camel route, transitive dependencies have to be directly added to the >>>>>>> project pom. >>>>>>> >>>>>>> 2. I have all my configurations defined in a maven project for >>>>>>> assembling the final features xml file. This of course doesn't make it >>>>>>> easy to use any of those configurations in camel integration tests since >>>>>>> configurations needed for config admin would have to be added to the >>>>>>> projects test resources. >>>>>>> >>>>>>> Obviously the two brief examples above focus mostly on Camel, but >>>>>>> the main problem is that I'm trying to figure out how I can no longer >>>>>>> make >>>>>>> everything provided in my bundle project provided scope without having >>>>>>> to >>>>>>> manually maintain the features files. >>>>>>> >>>>>>> That being said, I was looking at Apache Ace, but I'm not sure if >>>>>>> using Apache Ace would cause it to be more work to do Karaf integration >>>>>>> testing since Apache Ace doesn't use Karaf features. I thought about >>>>>>> maybe >>>>>>> using OBR, but we use Artifactory and so I'm not sure if going down the >>>>>>> OBR >>>>>>> route might ultimately not be possible (I could be wrong but Artifactory >>>>>>> doesn't appear to have OBR support), also I read that OSGi has moved >>>>>>> away >>>>>>> from OBR to different repository mechanism (forget offhand what it's >>>>>>> called). I looked into Apache Cave, but I don't want to rock the boat >>>>>>> where I'm at yet since I'm the only one pushing Karaf and OSGi >>>>>>> currently. >>>>>>> I don't want to try to push things out of my organizations comfort zone >>>>>>> by >>>>>>> getting too radical in my project deployment. I haven't gotten to read >>>>>>> into the Karaf 4.0 profiles yet. >>>>>>> >>>>>>> What it really boils down to is that I'm not sure which deployment >>>>>>> approach with Karaf would be the best to use out of all the options with >>>>>>> the goal of moving to a continuous deployment model. >>>>>>> >>>>>>> Hoping someone might be willing to comment on how they solved these >>>>>>> issues or maybe what direction I should look at going down that will >>>>>>> allow >>>>>>> me to improve these aspects. It took me a while to get things where >>>>>>> they >>>>>>> are at, I want to be pretty confident in what path I go down next since >>>>>>> if >>>>>>> it doesn't pan out, it will be a lot of potentially wasted time and >>>>>>> effort. >>>>>>> :) >>>>>>> >>>>>>> Thanks in advance for any thoughts/suggestions. >>>>>>> >>>>>>> Ryan >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Apache Member >>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>>>>> Committer & Project Lead >>>>>> blog <http://notizblog.nierbeck.de/> >>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>>>>> >>>>>> Software Architect / Project Manager / Scrum Master >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> >>>> Apache Member >>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>>> Committer & Project Lead >>>> blog <http://notizblog.nierbeck.de/> >>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>>> >>>> Software Architect / Project Manager / Scrum Master >>>> >>>> >> >> >> -- >> >> Apache Member >> Apache Karaf <http://karaf.apache.org/> Committer & PMC >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer >> & Project Lead >> blog <http://notizblog.nierbeck.de/> >> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >> >> Software Architect / Project Manager / Scrum Master >> >> > > > -- > > Apache Member > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & > Project Lead > blog <http://notizblog.nierbeck.de/> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > > Software Architect / Project Manager / Scrum Master > >
