Hi, >> Not sure if Artifactory can function as an OBR like Nexus still
this reminds me of JFrogs booth at last years JAX (Java Experience Convention): - "Do you support OBR in Artifactory via plugins or similar?" - "No, we don't believe in OSGi!" That about ended our conversation ... Cheers, Michael 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 > >
