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
