You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Brad Johnson <br...@mediadriver.com> on 2016/09/12 21:16:12 UTC
Karaf profiles problem...
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))"]]
Re: Karaf profiles problem...
Posted by Brad Johnson <br...@mediadriver.com>.
It was simple enough for the time simply to recompile my project with 1.7
until I can download the profiles project and set the value. I may be able
to override the Maven resources plugin down in my my profiles project. My
version may be a bit older as well. I noticed that in the parent's
parent's POM the compiler is set at 1.8.
I think the registry/static mechanics for putting together zipped karaf
instances is brilliant. It works very well. I have a CXF SOAP/REST server
with routes in Camel to various bundles and it zips to 30MB with Jetty.
Now that's beautiful for Microservices. Just one example of how I could see
this being used is one instance could be a SOAP/REST gateway to the outside
world talking via routes to various instances that each contain the
business logic and integration points for some individual service handling
that route might be via JMS, SOAP or what have you. Want to install an
update? Start the updated version of the karaf and then switch the gateway
to use the address of the new one instead of the old one. These might sit
in an Amazon VPC with on the single front end VM exposed to the world and
handling security.
Problems? Then switch it back. As I said, I can see that as one among
many uses.
The new CDI that you guys are putting in and the Camel 2.17.3 are also
fantastic. I've never lashed up code so fast using blueprint. And I
certainly haven't lashed up tests as fast in CamelBlueprintTestSupport as I
have with the Camel CDI test runner. And that's a big deal when trying to
work under pressure and still keep one's unit tests up-to-date. If it gets
to be too much of a hassle that tends to fall by the wayside
unfortunately. And if I never have to touch XML again in my life I'll be a
much happier camper.
The only issue I had the CDI and Camel was when installing it via the
profiles. The bundles would load up just fine but the Routes wouldn't get
triggered and none of the code loaded up. I'd see all the relevant PAX CDI
bundles install themselves at RC1.
In this particular case I just quickly added in the blueprint files. It
was much easier to do because I had all the tests running via CDI and the
only thing I was using the blueprint for was the glue and some
service/references. I now Guillaume has already added a new mechanism for
OSGi service exposure and reference to the new CDI and that's very cool.
In a way I see the CDI for OSGi as what SCR should have been (I'm sure
thunder and lightning is going to strike me at saying such heretical
things.)
In any case, whether it's just my set up not being quite right for the
Camel CDI to properly bootstrap the routes or if that still requires some
work I'm pretty excited about it. I have to go into organizations all the
time and teach developers how to use blueprint. And answer the same sort
of questions about why the blueprint can't find there beans (misspelling)
or why their properties won't reload (wrong version of blueprint cm) or why
their CBTS can't find a service (not mocked or exported via
src/test/resources or overrides of the services in the test harness). And
so on.
Since I've used blueprint for quite awhile the switch to CDI is a bit
left-handed for me but well worth and always a delight to just have it work
without a bunch of getters/setters, explicit instantiation and nested
beans, and so on.
It sort of feels like catching up in that regard to a lot of what J2EE has
had for awhile. And I think it's fantastic. I'd even be OK using SCR for
bundle externals and CDI for bundle internals but now the Guillaume has
added service export and references to the CDI implementation half the need
for that goes away. There are still other places where it may be
necessary.
Anyway, bravo guys. Bravo.
Brad
On Tue, Sep 13, 2016 at 2:59 PM, Guillaume Nodet <gn...@apache.org> wrote:
> 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 <bi...@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" <gn...@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 <br...@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 <
>>>> bimargulies@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson <
>>>>> brad.johnson@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 <
>>>>>> bimargulies@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.johnson@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 <
>>>>>>>> bimargulies@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.johnson@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: gnodet@redhat.com
>>> Web: http://fusesource.com
>>> Blog: http://gnodet.blogspot.com/
>>>
>>>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
Re: Karaf profiles problem...
Posted by Guillaume Nodet <gn...@apache.org>.
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 <bi...@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" <gn...@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 <br...@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 <
>>> bimargulies@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson <
>>>> brad.johnson@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 <
>>>>> bimargulies@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.johnson@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 <
>>>>>>> bimargulies@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.johnson@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: gnodet@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>
>>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: Karaf profiles problem...
Posted by Benson Margulies <bi...@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" <gn...@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 <br...@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 <bimargulies@gmail.com
>> > wrote:
>>
>>>
>>>
>>> On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson <
>>> brad.johnson@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 <
>>>> bimargulies@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.johnson@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 <
>>>>>> bimargulies@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.johnson@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: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
Re: Karaf profiles problem...
Posted by Guillaume Nodet <gn...@apache.org>.
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 <br...@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-
> static-distributions-td4037132.html
>
> On Tue, Sep 13, 2016 at 12:53 PM, Benson Margulies <bi...@gmail.com>
> wrote:
>
>>
>>
>> On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson <
>> brad.johnson@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 <bimargulies@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.johnson@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 <
>>>>> bimargulies@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.johnson@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: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: Karaf profiles problem...
Posted by Brad Johnson <br...@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-static-distributions-td4037132.html
On Tue, Sep 13, 2016 at 12:53 PM, Benson Margulies <bi...@gmail.com>
wrote:
>
>
> On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson <
> brad.johnson@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 <bi...@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.johnson@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 <
>>>> bimargulies@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.johnson@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))"]]
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Karaf profiles problem...
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson <brad.johnson@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 <bi...@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.johnson@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 <bimargulies@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.johnson@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=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))"]]
>>>>>
>>>>
>>>>
>>>
>>
>
Re: Karaf profiles problem...
Posted by Brad Johnson <br...@mediadriver.com>.
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 <bi...@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.johnson@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 <bi...@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.johnson@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=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))"]]
>>>>
>>>
>>>
>>
>
Re: Karaf profiles problem...
Posted by Benson Margulies <bi...@gmail.com>.
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.johnson@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 <bi...@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.johnson@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=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))"]]
>>>
>>
>>
>
Re: Karaf profiles problem...
Posted by Brad Johnson <br...@mediadriver.com>.
<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 <bi...@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.johnson@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=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))"]]
>>
>
>
Re: Karaf profiles problem...
Posted by Benson Margulies <bi...@gmail.com>.
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 <br...@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=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))"]]
>