Fwiw, profiles define the same kind of input that you can give to the assembly goal, but with a few additional goodies (inheritance, configuration, etc...) which make things easier in some use cases. Internally, the startup, boot and installed stages are converted to profiles for the assembly builder.
2016-09-13 20:37 GMT+02:00 Brad Johnson <[email protected]>: > I may have to try it that way. I'm using 4.0.6 as well. The profiles is > really using the karaf maven plugin under the covers and creating a set of > standard profiles. At least that's the intent of it. It was when I > stumbled on this that I decided that this might be the thing to look at for > the future. It actually works fairly well and after installing the > standard profiles I then have my application specific profile and a > features file associated with it. > > http://karaf.922171.n3.nabble.com/HEADS-UP-Profiles-and- > static-distributions-td4037132.html > > On Tue, Sep 13, 2016 at 12:53 PM, Benson Margulies <[email protected]> > wrote: > >> >> >> On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson < >> [email protected]> wrote: >> >>> 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. >>> >> >> I use Karaf 4.0.6. >> >> I have only a minimal set of bundles. I build several variations with >> different things included. >> >> I do it pretty easily with the karaf-maven-plugin making an assembly. >> >> Java8 works. >> >> >> >>> >>> 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=deve >>>>>>> lopment-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))"]] >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
