No profiles contain only bundles, features, configurations.
The javase config has to be configured in the configuration section of the
maven plugin as you already indicated:

 <configuration>
    <javase>1.8</javase>
  </configuration>

2016-09-13 21:47 GMT+02:00 Benson Margulies <bimargul...@gmail.com>:

> Is there then a missing feature to allow the spec of the j2se version?
>
> On Sep 13, 2016 3:44 PM, "Guillaume Nodet" <gno...@apache.org> 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 <brad.john...@mediadriver.com>:
>>
>>> 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 <
>>> bimargul...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson <
>>>> brad.john...@mediadriver.com> 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 <
>>>>> bimargul...@gmail.com> 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 <
>>>>>> brad.john...@mediadriver.com> 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 <
>>>>>>> bimargul...@gmail.com> 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 <
>>>>>>>> brad.john...@mediadriver.com> 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: gno...@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>
>>


-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Reply via email to