Is there then a missing feature to allow the spec of the j2se version? On Sep 13, 2016 3:44 PM, "Guillaume Nodet" <[email protected]> wrote:
> 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-stat >> ic-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/ > >
