Karaf profiles problem...

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Karaf profiles problem...

Brad Johnson
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))"]]
Reply | Threaded
Open this post in threaded view
|

Re: Karaf profiles problem...

Benson Margulies
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 <[hidden email]> 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))"]]

Reply | Threaded
Open this post in threaded view
|

Re: Karaf profiles problem...

Brad Johnson
    <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 <[hidden email]> 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 <[hidden email]> 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))"]]


Reply | Threaded
Open this post in threaded view
|

Re: Karaf profiles problem...

Benson Margulies
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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))"]]



Reply | Threaded
Open this post in threaded view
|

Re: Karaf profiles problem...

Brad Johnson
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.


Brad

On Tue, Sep 13, 2016 at 5:45 AM, Benson Margulies <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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))"]]




Reply | Threaded
Open this post in threaded view
|

Re: Karaf profiles problem...

Benson Margulies


On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson <[hidden email]> 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.


Brad

On Tue, Sep 13, 2016 at 5:45 AM, Benson Margulies <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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))"]]





Reply | Threaded
Open this post in threaded view
|

Re: Karaf profiles problem...

Brad Johnson
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.


On Tue, Sep 13, 2016 at 12:53 PM, Benson Margulies <[hidden email]> wrote:


On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson <[hidden email]> 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.


Brad

On Tue, Sep 13, 2016 at 5:45 AM, Benson Margulies <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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))"]]






Reply | Threaded
Open this post in threaded view
|

Re: Karaf profiles problem...

Guillaume Nodet-2
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 <[hidden email]>:
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.


On Tue, Sep 13, 2016 at 12:53 PM, Benson Margulies <[hidden email]> wrote:


On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson <[hidden email]> 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.


Brad

On Tue, Sep 13, 2016 at 5:45 AM, Benson Margulies <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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))"]]









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


Reply | Threaded
Open this post in threaded view
|

Re: Karaf profiles problem...

Benson Margulies

Is there then a missing feature to allow the spec of the j2se version?


On Sep 13, 2016 3:44 PM, "Guillaume Nodet" <[hidden email]> 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 <[hidden email]>:
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.


On Tue, Sep 13, 2016 at 12:53 PM, Benson Margulies <[hidden email]> wrote:


On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson <[hidden email]> 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.


Brad

On Tue, Sep 13, 2016 at 5:45 AM, Benson Margulies <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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))"]]









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


Reply | Threaded
Open this post in threaded view
|

Re: Karaf profiles problem...

Guillaume Nodet-2
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 <[hidden email]>:

Is there then a missing feature to allow the spec of the j2se version?


On Sep 13, 2016 3:44 PM, "Guillaume Nodet" <[hidden email]> 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 <[hidden email]>:
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.


On Tue, Sep 13, 2016 at 12:53 PM, Benson Margulies <[hidden email]> wrote:


On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson <[hidden email]> 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.


Brad

On Tue, Sep 13, 2016 at 5:45 AM, Benson Margulies <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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))"]]









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





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


Reply | Threaded
Open this post in threaded view
|

Re: Karaf profiles problem...

Brad Johnson
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 <[hidden email]> 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 <[hidden email]>:

Is there then a missing feature to allow the spec of the j2se version?


On Sep 13, 2016 3:44 PM, "Guillaume Nodet" <[hidden email]> 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 <[hidden email]>:
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.


On Tue, Sep 13, 2016 at 12:53 PM, Benson Margulies <[hidden email]> wrote:


On Tue, Sep 13, 2016 at 12:53 PM, Brad Johnson <[hidden email]> 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.


Brad

On Tue, Sep 13, 2016 at 5:45 AM, Benson Margulies <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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))"]]









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





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