Hi Ryan, see comments inline.
regards, Achim 2015-04-12 0:37 GMT+02:00 Ryan Moquin <[email protected]>: > 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" <[email protected]> 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 <[email protected]>: >> >>> 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
