I think the profiles mechanics are from karaf 4(?) In any case it allows you to create greatly slimmed down version of karaf with the required bundles already installed so one doesn't have to manually run features installs from the shell. Just fire it up and everything is there. The project I'm working on right now has CXF, PAX-CDI, Camel (cdi, blueprint, etc.) When I'm done it runs anywhere from 30MB to 50MB for a self-contained application. There's a good reason to do that right now in what I'm working on. While I'm making a larger application where the pieces will be split between different installs at different locations, I'm creating this self-contained "developer's" edition so anyone who wants to work with APIs can and it will react pretty much as it would if he production version is installed.
After a bit of fiddling to learn it it's pretty straightfoward and a great mechanism. I could see using it to create microservices based on bundles and relevant parts of the various libraries. https://github.com/apache/karaf/tree/master/demos/profiles Brad On Tue, Sep 13, 2016 at 5:45 AM, Benson Margulies <[email protected]> wrote: > I've never used Karaf profiles. I use the karaf-maven-plugin to make > assemblies, and I add that notation to the configuration, and I use java8 > and all is well. > > > On Mon, Sep 12, 2016 at 11:26 PM, Brad Johnson < > [email protected]> wrote: > >> <parent> >> <groupId>org.apache.karaf</groupId> >> <artifactId>karaf</artifactId> >> <version>4.0.6</version> >> <relativePath>../../pom.xml</relativePath> >> </parent> >> >> If I brought that down and modified it locally that's the case. But what >> I'd prefer is to have some properties settings in my child POM that could >> override the Java version (or other aspects as well.) But the karaf >> profile/static registry mechanism is really just pulling a zipped copy of >> karaf and then running through a bunch of profiles and installing the >> specified content including my features file. >> >> When I changed my project to use 1.7 it works. Fortunately I'm early in >> the process so there are only a few lambdas (mainly in test) that I had to >> modify to get this to run right. Right now I'm not too concerned about it >> as I have some other details to work out. With the blueprint version >> working I want to go back to the CDI version and get that working as well. >> >> Then I can worry about changing the branding package and name of the zip >> file and other items. >> >> Brad >> >> On Mon, Sep 12, 2016 at 7:59 PM, Benson Margulies <[email protected]> >> wrote: >> >>> Are you sure you don't just need: >>> >>> <javase>1.8</javase> >>> >>> in your <configuration/> of the karaf-maven-plugin? >>> >>> >>> On Mon, Sep 12, 2016 at 5:16 PM, Brad Johnson < >>> [email protected]> wrote: >>> >>>> Last night I was trying to use the new Camel 2.17.3 CDI with pax-cdi in >>>> the karaf registry/static profile mechanism in 4.0.6 that permits creating >>>> small subsets of functionality and zipping them up. I've tried it before >>>> with good success and figured the problems I was having were related to my >>>> features and profile set up. >>>> >>>> After some fiddling getting the Camel profile pointed to the right and >>>> adding in the camel-cdi in the profile's feature list and debugging my >>>> features file I kept getting hung up right at the last minute. Even with >>>> debugging it didn't make much sense to me. >>>> >>>> So I switched over to blueprint quickly to see how that would work and >>>> I ran into the same error. Finally I took a harder look and realized it >>>> was complaining about not being able to find Java 1.8 required by the >>>> bundle. >>>> >>>> My IDE is set to that but it appears that the Java version is hard >>>> coded in the org.apache.karaf/karaf/4.0.6 file and unsettable by the >>>> child projects. I'm not sure I'd call that a bug exactly but it appears >>>> that I'll either have to set my compiler preferences back to 1.7 for my >>>> project or download the karaf 4.0.6 and recompile or override the maven >>>> plugins in the lower level projects. >>>> >>>> Seems like that should be settable at a lower level. Java 1.7 is >>>> getting somewhat long in the tooth and it's a shame to have to retreat back >>>> to an earlier compiler version. I can't be 100% sure but after debugging >>>> and getting rid of any other errors, I hit this. >>>> >>>> Unable to build assembly: Unable to resolve root: missing requirement >>>> [root] osgi.identity; osgi.identity=development-all; type=karaf.feature; >>>> filter:="(&(osgi.identity=development-all)(type=karaf.feature))" >>>> [caused by: Unable to resolve panda-development-all/0.0.1.SNAPSHOT: >>>> missing requirement [development-all/0.0.1.SNAPSHOT] osgi.identity; >>>> osgi.identity=commons; type=osgi.bundle; >>>> version="[0.0.1.SNAPSHOT,0.0.1.SNAPSHOT]"; >>>> resolution:=mandatory [caused by: Unable to resolve commons/0.0.1.SNAPSHOT: >>>> missing requirement [commons/0.0.1.SNAPSHOT] osgi.ee; filter:="(&( >>>> osgi.ee=JavaSE)(version=1.8))"]] >>>> >>> >>> >> >
