Examples?

[Brad Johnson]

Are there any examples/sample code for this?  I find it a fascinating idea.  I could see some cases for testing.

http://aries.apache.org/modules/blueprintnoosgi.html

[Guillaume Nodet-2]

You have some examples in the unit tests :

  https://github.com/apache/aries/blob/trunk/blueprint/blueprint-noosgi/src/test/java/org/apache/aries/blueprint/BlueprintContainerTest.java

Also, the last release of blueprint-noosgi is a bit old, we may want to do a new release with more recent versions of blueprint-core, though it should work well enough.

2016-04-17 1:22 GMT+02:00 Brad Johnson <[hidden email]>:

Are there any examples/sample code for this?  I find it a fascinating idea.  I could see some cases for testing.

http://aries.apache.org/modules/blueprintnoosgi.html

--

[Brad Johnson]

Thanks.  I'll give it a look.  I have a project coming up where I'm developing a new endpoint to send updates of information coming in from a payment processor.  So I'll have a CBR in line looking for updates to information on request/response.  Internally there are a different divisions interested in that information and I have to set up a dummy web server/service to serve up an API so that my application can call it (to do a prototype/PoC).  So having a little blueprint bootstrap mechanism to set up a JAX WS/CXF server would be spankin'.  If they continue with their obsession with Docker it might become even more relevant since these self-contained bundled applications become something like half-way between what a WAR and OSGi are.  It obviously has to include all its dependencies like a WAR but it can run outside of a container.

By that I mean, a Docker image might have some blueprint bootstrap with a Tanukisoft Java Service Wrapper or equivalent.  I can imagine a new set of EIPs springing up around that. A small applciation, for example, that boots in a DMZ and exposes a Java annotated interface with certain security configurations and then turns around and uses the same interface to make a service call inside the firewall with different security and credentials.  A tiny router/firewall EIP for Docker. 

Part of the issue I run into currently is many of my clients are not using straight open source but going through a well known commercial organization so licensing becomes an issue.  So as different technologies get thrust at me because clients like them and want to adopt them and I find other technologies like blueprint NoOSGi that allow me to use the karaf based solutions for the more integrated enterprise but also repurpose the same XML and Java for small non-enterprise applications I become intrigued.

And I don't know how often I want to do integration testing where being able to boot up small test applications.  I certainly could turn around and use Spring for that sort of work but now me and my teams would have to switch paradigms.

Obviously a lot of that is still just hand waving and scheming on my part.  Until one starts putting nails in it it is hard to tell if it'll stand up or not.

Brad

On Sun, Apr 17, 2016 at 5:46 AM, Guillaume Nodet <[hidden email]> wrote:

You have some examples in the unit tests :

  https://github.com/apache/aries/blob/trunk/blueprint/blueprint-noosgi/src/test/java/org/apache/aries/blueprint/BlueprintContainerTest.java

Also, the last release of blueprint-noosgi is a bit old, we may want to do a new release with more recent versions of blueprint-core, though it should work well enough.

2016-04-17 1:22 GMT+02:00 Brad Johnson <[hidden email]>:

Are there any examples/sample code for this?  I find it a fascinating idea.  I could see some cases for testing.

http://aries.apache.org/modules/blueprintnoosgi.html

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

Email: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

[Guillaume Nodet-2]

If you end up with problems or limitations in Blueprint noOSGi, let us know.

I'd be happy to discuss and eventually fix any problems you have.

2016-04-17 17:36 GMT+02:00 Brad Johnson <[hidden email]>:

Thanks.  I'll give it a look.  I have a project coming up where I'm developing a new endpoint to send updates of information coming in from a payment processor.  So I'll have a CBR in line looking for updates to information on request/response.  Internally there are a different divisions interested in that information and I have to set up a dummy web server/service to serve up an API so that my application can call it (to do a prototype/PoC).  So having a little blueprint bootstrap mechanism to set up a JAX WS/CXF server would be spankin'.  If they continue with their obsession with Docker it might become even more relevant since these self-contained bundled applications become something like half-way between what a WAR and OSGi are.  It obviously has to include all its dependencies like a WAR but it can run outside of a container.

By that I mean, a Docker image might have some blueprint bootstrap with a Tanukisoft Java Service Wrapper or equivalent.  I can imagine a new set of EIPs springing up around that. A small applciation, for example, that boots in a DMZ and exposes a Java annotated interface with certain security configurations and then turns around and uses the same interface to make a service call inside the firewall with different security and credentials.  A tiny router/firewall EIP for Docker. 

Part of the issue I run into currently is many of my clients are not using straight open source but going through a well known commercial organization so licensing becomes an issue.  So as different technologies get thrust at me because clients like them and want to adopt them and I find other technologies like blueprint NoOSGi that allow me to use the karaf based solutions for the more integrated enterprise but also repurpose the same XML and Java for small non-enterprise applications I become intrigued.

And I don't know how often I want to do integration testing where being able to boot up small test applications.  I certainly could turn around and use Spring for that sort of work but now me and my teams would have to switch paradigms.

Obviously a lot of that is still just hand waving and scheming on my part.  Until one starts putting nails in it it is hard to tell if it'll stand up or not.

Brad

On Sun, Apr 17, 2016 at 5:46 AM, Guillaume Nodet <[hidden email]> wrote:

You have some examples in the unit tests :

  https://github.com/apache/aries/blob/trunk/blueprint/blueprint-noosgi/src/test/java/org/apache/aries/blueprint/BlueprintContainerTest.java

Also, the last release of blueprint-noosgi is a bit old, we may want to do a new release with more recent versions of blueprint-core, though it should work well enough.

2016-04-17 1:22 GMT+02:00 Brad Johnson <[hidden email]>:

Are there any examples/sample code for this?  I find it a fascinating idea.  I could see some cases for testing.

http://aries.apache.org/modules/blueprintnoosgi.html

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

Email: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

--

[Brad Johnson]

I'll give it a try this week and see what I find.  Obviously I'm going to use it in a very limited way and wouldn't expect a lot of the features I'd normally expect with karaf/blueprint.  

On Sun, Apr 17, 2016 at 1:04 PM, Guillaume Nodet <[hidden email]> wrote:

If you end up with problems or limitations in Blueprint noOSGi, let us know.

I'd be happy to discuss and eventually fix any problems you have.

2016-04-17 17:36 GMT+02:00 Brad Johnson <[hidden email]>:

Thanks.  I'll give it a look.  I have a project coming up where I'm developing a new endpoint to send updates of information coming in from a payment processor.  So I'll have a CBR in line looking for updates to information on request/response.  Internally there are a different divisions interested in that information and I have to set up a dummy web server/service to serve up an API so that my application can call it (to do a prototype/PoC).  So having a little blueprint bootstrap mechanism to set up a JAX WS/CXF server would be spankin'.  If they continue with their obsession with Docker it might become even more relevant since these self-contained bundled applications become something like half-way between what a WAR and OSGi are.  It obviously has to include all its dependencies like a WAR but it can run outside of a container.

By that I mean, a Docker image might have some blueprint bootstrap with a Tanukisoft Java Service Wrapper or equivalent.  I can imagine a new set of EIPs springing up around that. A small applciation, for example, that boots in a DMZ and exposes a Java annotated interface with certain security configurations and then turns around and uses the same interface to make a service call inside the firewall with different security and credentials.  A tiny router/firewall EIP for Docker. 

Part of the issue I run into currently is many of my clients are not using straight open source but going through a well known commercial organization so licensing becomes an issue.  So as different technologies get thrust at me because clients like them and want to adopt them and I find other technologies like blueprint NoOSGi that allow me to use the karaf based solutions for the more integrated enterprise but also repurpose the same XML and Java for small non-enterprise applications I become intrigued.

And I don't know how often I want to do integration testing where being able to boot up small test applications.  I certainly could turn around and use Spring for that sort of work but now me and my teams would have to switch paradigms.

Obviously a lot of that is still just hand waving and scheming on my part.  Until one starts putting nails in it it is hard to tell if it'll stand up or not.

Brad

On Sun, Apr 17, 2016 at 5:46 AM, Guillaume Nodet <[hidden email]> wrote:

You have some examples in the unit tests :

  https://github.com/apache/aries/blob/trunk/blueprint/blueprint-noosgi/src/test/java/org/apache/aries/blueprint/BlueprintContainerTest.java

Also, the last release of blueprint-noosgi is a bit old, we may want to do a new release with more recent versions of blueprint-core, though it should work well enough.

2016-04-17 1:22 GMT+02:00 Brad Johnson <[hidden email]>:

Are there any examples/sample code for this?  I find it a fascinating idea.  I could see some cases for testing.

http://aries.apache.org/modules/blueprintnoosgi.html

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

Email: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

Email: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

[Daniel Kulp]

I believe Sergey also has a systest in CXF (systests/jaxrs/src/test/resources/jaxrs_soap_blueprint/)  that uses this.   That might be another place to look if you are interested in using it with CXF.

Dan

> On Apr 17, 2016, at 11:36 AM, Brad Johnson <[hidden email]> wrote:
>
> Thanks.  I'll give it a look.  I have a project coming up where I'm developing a new endpoint to send updates of information coming in from a payment processor.  So I'll have a CBR in line looking for updates to information on request/response.  Internally there are a different divisions interested in that information and I have to set up a dummy web server/service to serve up an API so that my application can call it (to do a prototype/PoC).  So having a little blueprint bootstrap mechanism to set up a JAX WS/CXF server would be spankin'.  If they continue with their obsession with Docker it might become even more relevant since these self-contained bundled applications become something like half-way between what a WAR and OSGi are.  It obviously has to include all its dependencies like a WAR but it can run outside of a container.
>
> By that I mean, a Docker image might have some blueprint bootstrap with a Tanukisoft Java Service Wrapper or equivalent.  I can imagine a new set of EIPs springing up around that. A small applciation, for example, that boots in a DMZ and exposes a Java annotated interface with certain security configurations and then turns around and uses the same interface to make a service call inside the firewall with different security and credentials.  A tiny router/firewall EIP for Docker.
>
> Part of the issue I run into currently is many of my clients are not using straight open source but going through a well known commercial organization so licensing becomes an issue.  So as different technologies get thrust at me because clients like them and want to adopt them and I find other technologies like blueprint NoOSGi that allow me to use the karaf based solutions for the more integrated enterprise but also repurpose the same XML and Java for small non-enterprise applications I become intrigued.
>
> And I don't know how often I want to do integration testing where being able to boot up small test applications.  I certainly could turn around and use Spring for that sort of work but now me and my teams would have to switch paradigms.
>
> Obviously a lot of that is still just hand waving and scheming on my part.  Until one starts putting nails in it it is hard to tell if it'll stand up or not.
>
> Brad
>
> On Sun, Apr 17, 2016 at 5:46 AM, Guillaume Nodet <[hidden email]> wrote:
> You have some examples in the unit tests :
>   https://github.com/apache/aries/blob/trunk/blueprint/blueprint-noosgi/src/test/java/org/apache/aries/blueprint/BlueprintContainerTest.java
>
> Also, the last release of blueprint-noosgi is a bit old, we may want to do a new release with more recent versions of blueprint-core, though it should work well enough.
>
> 2016-04-17 1:22 GMT+02:00 Brad Johnson <[hidden email]>:
> Are there any examples/sample code for this?  I find it a fascinating idea.  I could see some cases for testing.
>
> http://aries.apache.org/modules/blueprintnoosgi.html
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: [hidden email]
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

[Christian Schneider]

Why do you want to use blueprint outside of OSGi?
Wouldnt it be easier to just package a small OSGI application as a docker image?

Karaf now has a static profile that allows to package an application quite like a microservice. Basically you create a tgz of the osgi framework + some karaf features + you own bundles.

Christian

On 17.04.2016 17:36, Brad Johnson wrote:

Thanks.  I'll give it a look.  I have a project coming up where I'm developing a new endpoint to send updates of information coming in from a payment processor.  So I'll have a CBR in line looking for updates to information on request/response.  Internally there are a different divisions interested in that information and I have to set up a dummy web server/service to serve up an API so that my application can call it (to do a prototype/PoC).  So having a little blueprint bootstrap mechanism to set up a JAX WS/CXF server would be spankin'.  If they continue with their obsession with Docker it might become even more relevant since these self-contained bundled applications become something like half-way between what a WAR and OSGi are.  It obviously has to include all its dependencies like a WAR but it can run outside of a container.

By that I mean, a Docker image might have some blueprint bootstrap with a Tanukisoft Java Service Wrapper or equivalent.  I can imagine a new set of EIPs springing up around that. A small applciation, for example, that boots in a DMZ and exposes a Java annotated interface with certain security configurations and then turns around and uses the same interface to make a service call inside the firewall with different security and credentials.  A tiny router/firewall EIP for Docker. 

Part of the issue I run into currently is many of my clients are not using straight open source but going through a well known commercial organization so licensing becomes an issue.  So as different technologies get thrust at me because clients like them and want to adopt them and I find other technologies like blueprint NoOSGi that allow me to use the karaf based solutions for the more integrated enterprise but also repurpose the same XML and Java for small non-enterprise applications I become intrigued.

And I don't know how often I want to do integration testing where being able to boot up small test applications.  I certainly could turn around and use Spring for that sort of work but now me and my teams would have to switch paradigms.

Obviously a lot of that is still just hand waving and scheming on my part.  Until one starts putting nails in it it is hard to tell if it'll stand up or not.

Brad

On Sun, Apr 17, 2016 at 5:46 AM, Guillaume Nodet <[hidden email]> wrote:

You have some examples in the unit tests :

  https://github.com/apache/aries/blob/trunk/blueprint/blueprint-noosgi/src/test/java/org/apache/aries/blueprint/BlueprintContainerTest.java

Also, the last release of blueprint-noosgi is a bit old, we may want to do a new release with more recent versions of blueprint-core, though it should work well enough.

2016-04-17 1:22 GMT+02:00 Brad Johnson <[hidden email]>:

Are there any examples/sample code for this?  I find it a fascinating idea.  I could see some cases for testing.

http://aries.apache.org/modules/blueprintnoosgi.html

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

Email: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

[Brad Johnson]

Christian,

That's probably somewhat more what I'd want.  Not necessarily even in a docker image but possibly.  That's one of the reasons I'm curious to see how Karaf boot looks when it comes out.  I haven't used the static profile mechanism in Karaf or the plugins associated with it in Maven yet.  For a small microservice sort of bundle what would be ideal is a Maven plugin that simply used the Maven dependencies and the framework and created a runnable or semi-runnable version of it. If it used the features as part of the build then for this purpose I'd just as soon have it read the features file and pull the required bundles in from that features file.  Perhaps that's what the static profiles do and I need to take the time to work with it.

To be honest I haven't had a lot of time to think it through as I'm still working in Fuse on a day-to-day basis but I'm faced with more and more problems where such static micro-container strategies with pre-packaged container and bundles will make sense.  In that case the slimmed down karaf that doesn't have the features resolver would be beneficial as well.  Perhaps think of it as karaf as an appliance.  An example of that might be a gateway appliance for deployment to a corporate DMZ.  It has certificates and authentication to grant access to identical web services inside the firewall that use different certificates and authentication perhaps authorization features but identical services.  That's a fairly static set of features and a standard project/design pattern could be set up for that.  When run it could create that appliance in ready to run form.  Ideally everything would be stuffed inside it that it needs to be deployed and perhaps I might even run it from my unit test and exercise those webservices.

Conceptually I always think of that with a Tanukisoft wrapper but realize that that isn't the right licensing model but it is the right idea I think.  In most cases I'd want to run something like that as a service on whatever platform. That's why conceptually I don't put Docker in the mix since to me that is just another level of abstraction that may or may not make sense depending on the context.  In many cases my clients aren't using Docker and I don't have a desire to push for it.

Brad

On Tue, Apr 26, 2016 at 10:37 AM, Christian Schneider <[hidden email]> wrote:

Why do you want to use blueprint outside of OSGi?
Wouldnt it be easier to just package a small OSGI application as a docker image?

Karaf now has a static profile that allows to package an application quite like a microservice. Basically you create a tgz of the osgi framework + some karaf features + you own bundles.

Christian

On 17.04.2016 17:36, Brad Johnson wrote:

Thanks.  I'll give it a look.  I have a project coming up where I'm developing a new endpoint to send updates of information coming in from a payment processor.  So I'll have a CBR in line looking for updates to information on request/response.  Internally there are a different divisions interested in that information and I have to set up a dummy web server/service to serve up an API so that my application can call it (to do a prototype/PoC).  So having a little blueprint bootstrap mechanism to set up a JAX WS/CXF server would be spankin'.  If they continue with their obsession with Docker it might become even more relevant since these self-contained bundled applications become something like half-way between what a WAR and OSGi are.  It obviously has to include all its dependencies like a WAR but it can run outside of a container.

By that I mean, a Docker image might have some blueprint bootstrap with a Tanukisoft Java Service Wrapper or equivalent.  I can imagine a new set of EIPs springing up around that. A small applciation, for example, that boots in a DMZ and exposes a Java annotated interface with certain security configurations and then turns around and uses the same interface to make a service call inside the firewall with different security and credentials.  A tiny router/firewall EIP for Docker. 

Part of the issue I run into currently is many of my clients are not using straight open source but going through a well known commercial organization so licensing becomes an issue.  So as different technologies get thrust at me because clients like them and want to adopt them and I find other technologies like blueprint NoOSGi that allow me to use the karaf based solutions for the more integrated enterprise but also repurpose the same XML and Java for small non-enterprise applications I become intrigued.

And I don't know how often I want to do integration testing where being able to boot up small test applications.  I certainly could turn around and use Spring for that sort of work but now me and my teams would have to switch paradigms.

Obviously a lot of that is still just hand waving and scheming on my part.  Until one starts putting nails in it it is hard to tell if it'll stand up or not.

Brad

On Sun, Apr 17, 2016 at 5:46 AM, Guillaume Nodet <[hidden email]> wrote:

You have some examples in the unit tests :

  https://github.com/apache/aries/blob/trunk/blueprint/blueprint-noosgi/src/test/java/org/apache/aries/blueprint/BlueprintContainerTest.java

Also, the last release of blueprint-noosgi is a bit old, we may want to do a new release with more recent versions of blueprint-core, though it should work well enough.

2016-04-17 1:22 GMT+02:00 Brad Johnson <[hidden email][hidden email]>:

Are there any examples/sample code for this?  I find it a fascinating idea.  I could see some cases for testing.

http://aries.apache.org/modules/blueprintnoosgi.html

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

Email: [hidden email][hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[Brad Johnson]

I looked at the profiles and static and find it interesting.  I'll have to work with it some.  There's obviously a bit of a mind shift there with the inheritance hierarchy.  In my mind's eye I saw this as something I'd run from a parent pom with a bunch of child bundle projects but it would likely be better as an aside project separate from the main build hierarchy itself. Which is fine.  Decouples it as a separate concern.  Just a bit different than I'd imagined.

I'll have to give it a swing.

On Tue, Apr 26, 2016 at 11:30 AM, Brad Johnson <[hidden email]> wrote:

Christian,

That's probably somewhat more what I'd want.  Not necessarily even in a docker image but possibly.  That's one of the reasons I'm curious to see how Karaf boot looks when it comes out.  I haven't used the static profile mechanism in Karaf or the plugins associated with it in Maven yet.  For a small microservice sort of bundle what would be ideal is a Maven plugin that simply used the Maven dependencies and the framework and created a runnable or semi-runnable version of it. If it used the features as part of the build then for this purpose I'd just as soon have it read the features file and pull the required bundles in from that features file.  Perhaps that's what the static profiles do and I need to take the time to work with it.

To be honest I haven't had a lot of time to think it through as I'm still working in Fuse on a day-to-day basis but I'm faced with more and more problems where such static micro-container strategies with pre-packaged container and bundles will make sense.  In that case the slimmed down karaf that doesn't have the features resolver would be beneficial as well.  Perhaps think of it as karaf as an appliance.  An example of that might be a gateway appliance for deployment to a corporate DMZ.  It has certificates and authentication to grant access to identical web services inside the firewall that use different certificates and authentication perhaps authorization features but identical services.  That's a fairly static set of features and a standard project/design pattern could be set up for that.  When run it could create that appliance in ready to run form.  Ideally everything would be stuffed inside it that it needs to be deployed and perhaps I might even run it from my unit test and exercise those webservices.

Conceptually I always think of that with a Tanukisoft wrapper but realize that that isn't the right licensing model but it is the right idea I think.  In most cases I'd want to run something like that as a service on whatever platform. That's why conceptually I don't put Docker in the mix since to me that is just another level of abstraction that may or may not make sense depending on the context.  In many cases my clients aren't using Docker and I don't have a desire to push for it.

Brad

On Tue, Apr 26, 2016 at 10:37 AM, Christian Schneider <[hidden email]> wrote:

Why do you want to use blueprint outside of OSGi?
Wouldnt it be easier to just package a small OSGI application as a docker image?

Karaf now has a static profile that allows to package an application quite like a microservice. Basically you create a tgz of the osgi framework + some karaf features + you own bundles.

Christian

On 17.04.2016 17:36, Brad Johnson wrote:

Thanks.  I'll give it a look.  I have a project coming up where I'm developing a new endpoint to send updates of information coming in from a payment processor.  So I'll have a CBR in line looking for updates to information on request/response.  Internally there are a different divisions interested in that information and I have to set up a dummy web server/service to serve up an API so that my application can call it (to do a prototype/PoC).  So having a little blueprint bootstrap mechanism to set up a JAX WS/CXF server would be spankin'.  If they continue with their obsession with Docker it might become even more relevant since these self-contained bundled applications become something like half-way between what a WAR and OSGi are.  It obviously has to include all its dependencies like a WAR but it can run outside of a container.

By that I mean, a Docker image might have some blueprint bootstrap with a Tanukisoft Java Service Wrapper or equivalent.  I can imagine a new set of EIPs springing up around that. A small applciation, for example, that boots in a DMZ and exposes a Java annotated interface with certain security configurations and then turns around and uses the same interface to make a service call inside the firewall with different security and credentials.  A tiny router/firewall EIP for Docker. 

Part of the issue I run into currently is many of my clients are not using straight open source but going through a well known commercial organization so licensing becomes an issue.  So as different technologies get thrust at me because clients like them and want to adopt them and I find other technologies like blueprint NoOSGi that allow me to use the karaf based solutions for the more integrated enterprise but also repurpose the same XML and Java for small non-enterprise applications I become intrigued.

And I don't know how often I want to do integration testing where being able to boot up small test applications.  I certainly could turn around and use Spring for that sort of work but now me and my teams would have to switch paradigms.

Obviously a lot of that is still just hand waving and scheming on my part.  Until one starts putting nails in it it is hard to tell if it'll stand up or not.

Brad

On Sun, Apr 17, 2016 at 5:46 AM, Guillaume Nodet <[hidden email]> wrote:

You have some examples in the unit tests :

  https://github.com/apache/aries/blob/trunk/blueprint/blueprint-noosgi/src/test/java/org/apache/aries/blueprint/BlueprintContainerTest.java

Also, the last release of blueprint-noosgi is a bit old, we may want to do a new release with more recent versions of blueprint-core, though it should work well enough.

2016-04-17 1:22 GMT+02:00 Brad Johnson <[hidden email][hidden email]>:

Are there any examples/sample code for this?  I find it a fascinating idea.  I could see some cases for testing.

http://aries.apache.org/modules/blueprintnoosgi.html

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

Email: [hidden email][hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[Christian Schneider]

I used the static profile here:
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app

It allows to package a very slim karaf with your features. All bundles
are directly referenced in the startup.properties. So there is no need
for a feature service if your bundles are fixed.
This makes karaf a lot easier to manage as you typically will not have
refresh issues.

The nice thing is that you can develop your application with normal
features and decide about the packaging at a very late state.

Christian

On 26.04.2016 23:36, Brad Johnson wrote:

> I looked at the profiles and static and find it interesting.  I'll
> have to work with it some.  There's obviously a bit of a mind shift
> there with the inheritance hierarchy.  In my mind's eye I saw this as
> something I'd run from a parent pom with a bunch of child bundle
> projects but it would likely be better as an aside project separate
> from the main build hierarchy itself. Which is fine.  Decouples it as
> a separate concern.  Just a bit different than I'd imagined.
>
> I'll have to give it a swing.
>

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[Jean-Baptiste Onofré]

I don't think Karaf is a lot easier: it's a different approach,
different topology. It's not the same use case/packaging.

It's exactly what karaf-boot is addressing: you use the annotations, we
deal with the packaging (you just define what you want).

FYI, the static profile exists since 4.0.0 (it came with Karaf 4 and
profile introduction) ;)

Regards
JB

On 04/27/2016 09:08 AM, Christian Schneider wrote:

> I used the static profile here:
> https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app
>
> It allows to package a very slim karaf with your features. All bundles
> are directly referenced in the startup.properties. So there is no need
> for a feature service if your bundles are fixed.
> This makes karaf a lot easier to manage as you typically will not have
> refresh issues.
>
> The nice thing is that you can develop your application with normal
> features and decide about the packaging at a very late state.
>
> Christian
>
> On 26.04.2016 23:36, Brad Johnson wrote:
>> I looked at the profiles and static and find it interesting.  I'll
>> have to work with it some.  There's obviously a bit of a mind shift
>> there with the inheritance hierarchy.  In my mind's eye I saw this as
>> something I'd run from a parent pom with a bunch of child bundle
>> projects but it would likely be better as an aside project separate
>> from the main build hierarchy itself. Which is fine.  Decouples it as
>> a separate concern.  Just a bit different than I'd imagined.
>>
>> I'll have to give it a swing.
>>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

[Brad Johnson]

Christian,

Very cool.  I'm working on a technical spike and PoC today so will give it a whirl.  I like that quite a bit.

Brad

On Wed, Apr 27, 2016 at 2:26 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

I don't think Karaf is a lot easier: it's a different approach, different topology. It's not the same use case/packaging.

It's exactly what karaf-boot is addressing: you use the annotations, we deal with the packaging (you just define what you want).

FYI, the static profile exists since 4.0.0 (it came with Karaf 4 and profile introduction) ;)

Regards
JB

On 04/27/2016 09:08 AM, Christian Schneider wrote:

I used the static profile here:
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app

It allows to package a very slim karaf with your features. All bundles
are directly referenced in the startup.properties. So there is no need
for a feature service if your bundles are fixed.
This makes karaf a lot easier to manage as you typically will not have
refresh issues.

The nice thing is that you can develop your application with normal
features and decide about the packaging at a very late state.

Christian

On <a href="tel:26.04.2016%2023" value="[phone]" target="_blank">26.04.2016 23:36, Brad Johnson wrote:

I looked at the profiles and static and find it interesting.  I'll
have to work with it some.  There's obviously a bit of a mind shift
there with the inheritance hierarchy.  In my mind's eye I saw this as
something I'd run from a parent pom with a bunch of child bundle
projects but it would likely be better as an aside project separate
from the main build hierarchy itself. Which is fine.  Decouples it as
a separate concern.  Just a bit different than I'd imagined.

I'll have to give it a swing.

--

Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

[Brad Johnson]

JB,

That's why I haven't had a chance to work with it yet since I'm working in Fuse exclusively and it is still on karaf 2.x.  So there hasn't been a chance to work with karaf 4 yet other than very basic stuff of running it.  But with the static profiles doing a proof of concept and self-contained prototype for demo and testing means that working with karaf 4 isn't out of line.  It's one of the issues I have with Fuse is that I'm always a step behind the world.  Although it does seem like Karaf 3 was sort of brief resting spot on the way to karaf 4 anyway.

So karaf-boot is leveraging the static profiles and using annotations to hook into that? I really think we may be in a back to the future situation with karaf.  Ten years ago virtual machines as appliances were a new rage.  Now they are rather common place.  Docker is an extension and a slimming of that in a way.  But karaf as appliances could really be an amazing market.  With the amazing goodness of OSGi and the karaf shell and being able to SSH in to a container for management that's pretty interesting stuff.  A whole different level of abstraction opens itself up.

I think as much out of releasing the mind from concerns as anything.  That's true when we started with OO and components and services and true at the appliance level as well.  When  you can look at an abstraction as a stand alone that can take care of its own needs you don't have to juggle it in your head.

The other day I'd mentioned a gateway appliance I'd like.  Feed it an appropriately decorated API interface and it creates server endpoints for incoming connections and makes client connections inward.  But one could also have appliances for isolating databases behind web services.  What the appliance makes possible is that physical and mental isolation where I just count on the service and don't have to think about how it co-exists in the same container with my other OSGi bundles.  While we all work hard to make sure our exports and private packages are kept properly in their place in their bundles not every craftsman is equal in skill.  And we all make mistakes.  Karaf as an appliance mitigates that somewhat.  If the young, bright developer I work with doesn't quite get the private package right and ends up with his bundle's contents exported to the world, well, if he's just exposing web services to isolate a database from the world then it isn't as serious a problem.

Things like Drools rules engines with routes on JMS, SOAP, REST coming into it with a highly constrained set of rules for domain specific problem also become nifty little appliances.  And so many of those have a nice fill in the logic feel to them.  By that I mean that 90% of the Maven and profiles are the same.  You just take the appliance outline and start working with the Camel, Java beans, and logic only.

And testing! By God testing!

Ahem. I don't know how many hours I've lost on CamelBlueprintTestSupport, PaxExam, and so on.  If I can button up a nice appliance and simply run some JUnit tests with web services on a black box I'm a happy camper.  One thing I've done in some of my tests environments that would work well with such black box appliances is put endpoint test simulator/stubs right in the bundles that are enabled/disabled by configuration flags.  One project I'm on right now provides a set of services for the enterprise to get things like Invoices.  Those REST and SOAP services use canonical models that have Dozer transforms to JDE models and a connection to JDE BSSVs (SOAP).  During testing I set the flag and instead of using an OSGi service to talk directly to JDE it uses a different OSGi service that simply serves up dummy data from a map of XStream data models that I keep tucked away inside.  But it let's me exercise all the routes, transforms, logic and deploy it early on for web tier folks to work against.  With the static mechanics I can make an appliance of that and switch from test data to actual JDE with the flick of a configuration file setting.  Or exercise it from my simple JUnit tests.  And Jenkins should be simpler too.

So yeah, this excites me a great deal.

Brad

On Wed, Apr 27, 2016 at 2:26 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

I don't think Karaf is a lot easier: it's a different approach, different topology. It's not the same use case/packaging.

It's exactly what karaf-boot is addressing: you use the annotations, we deal with the packaging (you just define what you want).

FYI, the static profile exists since 4.0.0 (it came with Karaf 4 and profile introduction) ;)

Regards
JB

On 04/27/2016 09:08 AM, Christian Schneider wrote:

I used the static profile here:
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app

It allows to package a very slim karaf with your features. All bundles
are directly referenced in the startup.properties. So there is no need
for a feature service if your bundles are fixed.
This makes karaf a lot easier to manage as you typically will not have
refresh issues.

The nice thing is that you can develop your application with normal
features and decide about the packaging at a very late state.

Christian

On <a href="tel:26.04.2016%2023" value="[phone]" target="_blank">26.04.2016 23:36, Brad Johnson wrote:

I looked at the profiles and static and find it interesting.  I'll
have to work with it some.  There's obviously a bit of a mind shift
there with the inheritance hierarchy.  In my mind's eye I saw this as
something I'd run from a parent pom with a bunch of child bundle
projects but it would likely be better as an aside project separate
from the main build hierarchy itself. Which is fine.  Decouples it as
a separate concern.  Just a bit different than I'd imagined.

I'll have to give it a swing.

--

Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

[Brad Johnson]

Christian,

Finally got a few minutes breathing room yesterday to work with some of the new plugins.  I like the karaf-maven-plugin and the features generation.  I'm not sure how much it is pulling that is absolutely necessary and how much it is getting as just a scrape.  It doesn't seem to differentiate on the test scope. Those are obviously not items I'd want in my features file.

The karaf assembly kicks off fine but of course when I try to use it with any of my existing projects I quickly run into a problem that my current projects uses Fuse specific items and I'll have to switch my BOM to make it work with the assembly.  I'll do that if I get some time today.

The assembly kicks off fine and pulls the karaf instance and begins but as soon as it runs into my features file it pukes on some of the dependencies. So the best bet would be to use the karaf-plugin and let it generate the features file for all my projects and then use those in the startup. 

I'll give it a shot today and see what happens.

Brad

On Wed, Apr 27, 2016 at 8:51 AM, Brad Johnson <[hidden email]> wrote:

JB,

That's why I haven't had a chance to work with it yet since I'm working in Fuse exclusively and it is still on karaf 2.x.  So there hasn't been a chance to work with karaf 4 yet other than very basic stuff of running it.  But with the static profiles doing a proof of concept and self-contained prototype for demo and testing means that working with karaf 4 isn't out of line.  It's one of the issues I have with Fuse is that I'm always a step behind the world.  Although it does seem like Karaf 3 was sort of brief resting spot on the way to karaf 4 anyway.

So karaf-boot is leveraging the static profiles and using annotations to hook into that? I really think we may be in a back to the future situation with karaf.  Ten years ago virtual machines as appliances were a new rage.  Now they are rather common place.  Docker is an extension and a slimming of that in a way.  But karaf as appliances could really be an amazing market.  With the amazing goodness of OSGi and the karaf shell and being able to SSH in to a container for management that's pretty interesting stuff.  A whole different level of abstraction opens itself up.

I think as much out of releasing the mind from concerns as anything.  That's true when we started with OO and components and services and true at the appliance level as well.  When  you can look at an abstraction as a stand alone that can take care of its own needs you don't have to juggle it in your head.

The other day I'd mentioned a gateway appliance I'd like.  Feed it an appropriately decorated API interface and it creates server endpoints for incoming connections and makes client connections inward.  But one could also have appliances for isolating databases behind web services.  What the appliance makes possible is that physical and mental isolation where I just count on the service and don't have to think about how it co-exists in the same container with my other OSGi bundles.  While we all work hard to make sure our exports and private packages are kept properly in their place in their bundles not every craftsman is equal in skill.  And we all make mistakes.  Karaf as an appliance mitigates that somewhat.  If the young, bright developer I work with doesn't quite get the private package right and ends up with his bundle's contents exported to the world, well, if he's just exposing web services to isolate a database from the world then it isn't as serious a problem.

Things like Drools rules engines with routes on JMS, SOAP, REST coming into it with a highly constrained set of rules for domain specific problem also become nifty little appliances.  And so many of those have a nice fill in the logic feel to them.  By that I mean that 90% of the Maven and profiles are the same.  You just take the appliance outline and start working with the Camel, Java beans, and logic only.

And testing! By God testing!

Ahem. I don't know how many hours I've lost on CamelBlueprintTestSupport, PaxExam, and so on.  If I can button up a nice appliance and simply run some JUnit tests with web services on a black box I'm a happy camper.  One thing I've done in some of my tests environments that would work well with such black box appliances is put endpoint test simulator/stubs right in the bundles that are enabled/disabled by configuration flags.  One project I'm on right now provides a set of services for the enterprise to get things like Invoices.  Those REST and SOAP services use canonical models that have Dozer transforms to JDE models and a connection to JDE BSSVs (SOAP).  During testing I set the flag and instead of using an OSGi service to talk directly to JDE it uses a different OSGi service that simply serves up dummy data from a map of XStream data models that I keep tucked away inside.  But it let's me exercise all the routes, transforms, logic and deploy it early on for web tier folks to work against.  With the static mechanics I can make an appliance of that and switch from test data to actual JDE with the flick of a configuration file setting.  Or exercise it from my simple JUnit tests.  And Jenkins should be simpler too.

So yeah, this excites me a great deal.

Brad

On Wed, Apr 27, 2016 at 2:26 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

I don't think Karaf is a lot easier: it's a different approach, different topology. It's not the same use case/packaging.

It's exactly what karaf-boot is addressing: you use the annotations, we deal with the packaging (you just define what you want).

FYI, the static profile exists since 4.0.0 (it came with Karaf 4 and profile introduction) ;)

Regards
JB

On 04/27/2016 09:08 AM, Christian Schneider wrote:

I used the static profile here:
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app

It allows to package a very slim karaf with your features. All bundles
are directly referenced in the startup.properties. So there is no need
for a feature service if your bundles are fixed.
This makes karaf a lot easier to manage as you typically will not have
refresh issues.

The nice thing is that you can develop your application with normal
features and decide about the packaging at a very late state.

Christian

On <a href="tel:26.04.2016%2023" value="[phone]" target="_blank">26.04.2016 23:36, Brad Johnson wrote:

I looked at the profiles and static and find it interesting.  I'll
have to work with it some.  There's obviously a bit of a mind shift
there with the inheritance hierarchy.  In my mind's eye I saw this as
something I'd run from a parent pom with a bunch of child bundle
projects but it would likely be better as an aside project separate
from the main build hierarchy itself. Which is fine.  Decouples it as
a separate concern.  Just a bit different than I'd imagined.

I'll have to give it a swing.

--

Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

[Brad Johnson]

 <feature prerequisite="true" dependency="false">wrap</feature>

That's the only issue it is barfing on right now.  I'll just have to run it down.

[ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.0.5:assembly (process-resources) on project paypal-app: Unable to build assembly: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=wrap; type=karaf.feature; version=0; filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))" [caused by: Unable to resolve wrap/0.0.0: missing requirement [wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap; type=osgi.bundle; version="[2.4.7,2.4.7]"; resolution:=mandatory [caused by: Unable to resolve org.ops4j.pax.url.wrap/2.4.7: missing requirement [org.ops4j.pax.url.wrap/2.4.7] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]] -> [Help 1]
[ERROR]

On Thu, Apr 28, 2016 at 9:30 AM, Brad Johnson <[hidden email]> wrote:

Christian,

Finally got a few minutes breathing room yesterday to work with some of the new plugins.  I like the karaf-maven-plugin and the features generation.  I'm not sure how much it is pulling that is absolutely necessary and how much it is getting as just a scrape.  It doesn't seem to differentiate on the test scope. Those are obviously not items I'd want in my features file.

The karaf assembly kicks off fine but of course when I try to use it with any of my existing projects I quickly run into a problem that my current projects uses Fuse specific items and I'll have to switch my BOM to make it work with the assembly.  I'll do that if I get some time today.

The assembly kicks off fine and pulls the karaf instance and begins but as soon as it runs into my features file it pukes on some of the dependencies. So the best bet would be to use the karaf-plugin and let it generate the features file for all my projects and then use those in the startup. 

I'll give it a shot today and see what happens.

Brad

On Wed, Apr 27, 2016 at 8:51 AM, Brad Johnson <[hidden email]> wrote:

JB,

That's why I haven't had a chance to work with it yet since I'm working in Fuse exclusively and it is still on karaf 2.x.  So there hasn't been a chance to work with karaf 4 yet other than very basic stuff of running it.  But with the static profiles doing a proof of concept and self-contained prototype for demo and testing means that working with karaf 4 isn't out of line.  It's one of the issues I have with Fuse is that I'm always a step behind the world.  Although it does seem like Karaf 3 was sort of brief resting spot on the way to karaf 4 anyway.

So karaf-boot is leveraging the static profiles and using annotations to hook into that? I really think we may be in a back to the future situation with karaf.  Ten years ago virtual machines as appliances were a new rage.  Now they are rather common place.  Docker is an extension and a slimming of that in a way.  But karaf as appliances could really be an amazing market.  With the amazing goodness of OSGi and the karaf shell and being able to SSH in to a container for management that's pretty interesting stuff.  A whole different level of abstraction opens itself up.

I think as much out of releasing the mind from concerns as anything.  That's true when we started with OO and components and services and true at the appliance level as well.  When  you can look at an abstraction as a stand alone that can take care of its own needs you don't have to juggle it in your head.

The other day I'd mentioned a gateway appliance I'd like.  Feed it an appropriately decorated API interface and it creates server endpoints for incoming connections and makes client connections inward.  But one could also have appliances for isolating databases behind web services.  What the appliance makes possible is that physical and mental isolation where I just count on the service and don't have to think about how it co-exists in the same container with my other OSGi bundles.  While we all work hard to make sure our exports and private packages are kept properly in their place in their bundles not every craftsman is equal in skill.  And we all make mistakes.  Karaf as an appliance mitigates that somewhat.  If the young, bright developer I work with doesn't quite get the private package right and ends up with his bundle's contents exported to the world, well, if he's just exposing web services to isolate a database from the world then it isn't as serious a problem.

Things like Drools rules engines with routes on JMS, SOAP, REST coming into it with a highly constrained set of rules for domain specific problem also become nifty little appliances.  And so many of those have a nice fill in the logic feel to them.  By that I mean that 90% of the Maven and profiles are the same.  You just take the appliance outline and start working with the Camel, Java beans, and logic only.

And testing! By God testing!

Ahem. I don't know how many hours I've lost on CamelBlueprintTestSupport, PaxExam, and so on.  If I can button up a nice appliance and simply run some JUnit tests with web services on a black box I'm a happy camper.  One thing I've done in some of my tests environments that would work well with such black box appliances is put endpoint test simulator/stubs right in the bundles that are enabled/disabled by configuration flags.  One project I'm on right now provides a set of services for the enterprise to get things like Invoices.  Those REST and SOAP services use canonical models that have Dozer transforms to JDE models and a connection to JDE BSSVs (SOAP).  During testing I set the flag and instead of using an OSGi service to talk directly to JDE it uses a different OSGi service that simply serves up dummy data from a map of XStream data models that I keep tucked away inside.  But it let's me exercise all the routes, transforms, logic and deploy it early on for web tier folks to work against.  With the static mechanics I can make an appliance of that and switch from test data to actual JDE with the flick of a configuration file setting.  Or exercise it from my simple JUnit tests.  And Jenkins should be simpler too.

So yeah, this excites me a great deal.

Brad

On Wed, Apr 27, 2016 at 2:26 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

I don't think Karaf is a lot easier: it's a different approach, different topology. It's not the same use case/packaging.

It's exactly what karaf-boot is addressing: you use the annotations, we deal with the packaging (you just define what you want).

FYI, the static profile exists since 4.0.0 (it came with Karaf 4 and profile introduction) ;)

Regards
JB

On 04/27/2016 09:08 AM, Christian Schneider wrote:

I used the static profile here:
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app

It allows to package a very slim karaf with your features. All bundles
are directly referenced in the startup.properties. So there is no need
for a feature service if your bundles are fixed.
This makes karaf a lot easier to manage as you typically will not have
refresh issues.

The nice thing is that you can develop your application with normal
features and decide about the packaging at a very late state.

Christian

On <a href="tel:26.04.2016%2023" value="[phone]" target="_blank">26.04.2016 23:36, Brad Johnson wrote:

I looked at the profiles and static and find it interesting.  I'll
have to work with it some.  There's obviously a bit of a mind shift
there with the inheritance hierarchy.  In my mind's eye I saw this as
something I'd run from a parent pom with a bunch of child bundle
projects but it would likely be better as an aside project separate
from the main build hierarchy itself. Which is fine.  Decouples it as
a separate concern.  Just a bit different than I'd imagined.

I'll have to give it a swing.

--

Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

[Christian Schneider]

The error indicates that pax logging is missing which would provide the
slf4j api.

Christian


On 28.04.2016 16:42, Brad Johnson wrote:

>  <feature prerequisite="true" dependency="false">wrap</feature>
>
> That's the only issue it is barfing on right now.  I'll just have to
> run it down.
>
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.5:assembly
> (process-resources) on project paypal-app: Unable to build assembly:
> Unable to resolve root: missing requirement [root] osgi.identity;
> osgi.identity=wrap; type=karaf.feature; version=0;
> filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
> [caused by: Unable to resolve wrap/0.0.0: missing requirement
> [wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap;
> type=osgi.bundle; version="[2.4.7,2.4.7]"; resolution:=mandatory
> [caused by: Unable to resolve org.ops4j.pax.url.wrap/2.4.7: missing
> requirement [org.ops4j.pax.url.wrap/2.4.7] osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
> -> [Help 1]
> [ERROR]
>

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[Jean-Baptiste Onofré]

Do you have framework and log <feature/> defined in your pom.xml ?

Regards
JB

On 04/28/2016 04:42 PM, Brad Johnson wrote:

>   <feature prerequisite="true" dependency="false">wrap</feature>
>
> That's the only issue it is barfing on right now.  I'll just have to run
> it down.
>
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.5:assembly
> (process-resources) on project paypal-app: Unable to build assembly:
> Unable to resolve root: missing requirement [root] osgi.identity;
> osgi.identity=wrap; type=karaf.feature; version=0;
> filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
> [caused by: Unable to resolve wrap/0.0.0: missing requirement
> [wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap;
> type=osgi.bundle; version="[2.4.7,2.4.7]"; resolution:=mandatory [caused
> by: Unable to resolve org.ops4j.pax.url.wrap/2.4.7: missing requirement
> [org.ops4j.pax.url.wrap/2.4.7] osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
> -> [Help 1]
> [ERROR]
>
> On Thu, Apr 28, 2016 at 9:30 AM, Brad Johnson
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Christian,
>
>     Finally got a few minutes breathing room yesterday to work with some
>     of the new plugins.  I like the karaf-maven-plugin and the features
>     generation.  I'm not sure how much it is pulling that is absolutely
>     necessary and how much it is getting as just a scrape.  It doesn't
>     seem to differentiate on the test scope. Those are obviously not
>     items I'd want in my features file.
>
>     The karaf assembly kicks off fine but of course when I try to use it
>     with any of my existing projects I quickly run into a problem that
>     my current projects uses Fuse specific items and I'll have to switch
>     my BOM to make it work with the assembly.  I'll do that if I get
>     some time today.
>
>     The assembly kicks off fine and pulls the karaf instance and begins
>     but as soon as it runs into my features file it pukes on some of the
>     dependencies. So the best bet would be to use the karaf-plugin and
>     let it generate the features file for all my projects and then use
>     those in the startup.
>
>     I'll give it a shot today and see what happens.
>
>     Brad
>
>     On Wed, Apr 27, 2016 at 8:51 AM, Brad Johnson
>     <[hidden email] <mailto:[hidden email]>>
>     wrote:
>
>         JB,
>
>         That's why I haven't had a chance to work with it yet since I'm
>         working in Fuse exclusively and it is still on karaf 2.x.  So
>         there hasn't been a chance to work with karaf 4 yet other than
>         very basic stuff of running it.  But with the static profiles
>         doing a proof of concept and self-contained prototype for demo
>         and testing means that working with karaf 4 isn't out of line.
>         It's one of the issues I have with Fuse is that I'm always a
>         step behind the world.  Although it does seem like Karaf 3 was
>         sort of brief resting spot on the way to karaf 4 anyway.
>
>         So karaf-boot is leveraging the static profiles and using
>         annotations to hook into that? I really think we may be in a
>         back to the future situation with karaf.  Ten years ago virtual
>         machines as appliances were a new rage.  Now they are rather
>         common place.  Docker is an extension and a slimming of that in
>         a way.  But karaf as appliances could really be an amazing
>         market.  With the amazing goodness of OSGi and the karaf shell
>         and being able to SSH in to a container for management that's
>         pretty interesting stuff.  A whole different level of
>         abstraction opens itself up.
>
>         I think as much out of releasing the mind from concerns as
>         anything.  That's true when we started with OO and components
>         and services and true at the appliance level as well.  When  you
>         can look at an abstraction as a stand alone that can take care
>         of its own needs you don't have to juggle it in your head.
>
>         The other day I'd mentioned a gateway appliance I'd like.  Feed
>         it an appropriately decorated API interface and it creates
>         server endpoints for incoming connections and makes client
>         connections inward.  But one could also have appliances for
>         isolating databases behind web services.  What the appliance
>         makes possible is that physical and mental isolation where I
>         just count on the service and don't have to think about how it
>         co-exists in the same container with my other OSGi bundles.
>         While we all work hard to make sure our exports and private
>         packages are kept properly in their place in their bundles not
>         every craftsman is equal in skill.  And we all make mistakes.
>         Karaf as an appliance mitigates that somewhat.  If the young,
>         bright developer I work with doesn't quite get the private
>         package right and ends up with his bundle's contents exported to
>         the world, well, if he's just exposing web services to isolate a
>         database from the world then it isn't as serious a problem.
>
>         Things like Drools rules engines with routes on JMS, SOAP, REST
>         coming into it with a highly constrained set of rules for domain
>         specific problem also become nifty little appliances.  And so
>         many of those have a nice fill in the logic feel to them.  By
>         that I mean that 90% of the Maven and profiles are the same.
>         You just take the appliance outline and start working with the
>         Camel, Java beans, and logic only.
>
>         And testing! By God testing!
>
>         Ahem. I don't know how many hours I've lost on
>         CamelBlueprintTestSupport, PaxExam, and so on.  If I can button
>         up a nice appliance and simply run some JUnit tests with web
>         services on a black box I'm a happy camper.  One thing I've done
>         in some of my tests environments that would work well with such
>         black box appliances is put endpoint test simulator/stubs right
>         in the bundles that are enabled/disabled by configuration
>         flags.  One project I'm on right now provides a set of services
>         for the enterprise to get things like Invoices.  Those REST and
>         SOAP services use canonical models that have Dozer transforms to
>         JDE models and a connection to JDE BSSVs (SOAP).  During testing
>         I set the flag and instead of using an OSGi service to talk
>         directly to JDE it uses a different OSGi service that simply
>         serves up dummy data from a map of XStream data models that I
>         keep tucked away inside.  But it let's me exercise all the
>         routes, transforms, logic and deploy it early on for web tier
>         folks to work against.  With the static mechanics I can make an
>         appliance of that and switch from test data to actual JDE with
>         the flick of a configuration file setting.  Or exercise it from
>         my simple JUnit tests.  And Jenkins should be simpler too.
>
>         So yeah, this excites me a great deal.
>
>         Brad
>
>         On Wed, Apr 27, 2016 at 2:26 AM, Jean-Baptiste Onofré
>         <[hidden email] <mailto:[hidden email]>> wrote:
>
>             I don't think Karaf is a lot easier: it's a different
>             approach, different topology. It's not the same use
>             case/packaging.
>
>             It's exactly what karaf-boot is addressing: you use the
>             annotations, we deal with the packaging (you just define
>             what you want).
>
>             FYI, the static profile exists since 4.0.0 (it came with
>             Karaf 4 and profile introduction) ;)
>
>             Regards
>             JB
>
>
>             On 04/27/2016 09:08 AM, Christian Schneider wrote:
>
>                 I used the static profile here:
>                 https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app
>
>                 It allows to package a very slim karaf with your
>                 features. All bundles
>                 are directly referenced in the startup.properties. So
>                 there is no need
>                 for a feature service if your bundles are fixed.
>                 This makes karaf a lot easier to manage as you typically
>                 will not have
>                 refresh issues.
>
>                 The nice thing is that you can develop your application
>                 with normal
>                 features and decide about the packaging at a very late
>                 state.
>
>                 Christian
>
>                 On 26.04.2016 23 <tel:26.04.2016%2023>:36, Brad Johnson
>                 wrote:
>
>                     I looked at the profiles and static and find it
>                     interesting.  I'll
>                     have to work with it some.  There's obviously a bit
>                     of a mind shift
>                     there with the inheritance hierarchy.  In my mind's
>                     eye I saw this as
>                     something I'd run from a parent pom with a bunch of
>                     child bundle
>                     projects but it would likely be better as an aside
>                     project separate
>                     from the main build hierarchy itself. Which is
>                     fine.  Decouples it as
>                     a separate concern.  Just a bit different than I'd
>                     imagined.
>
>                     I'll have to give it a swing.
>
>
>
>             --
>             Jean-Baptiste Onofré
>             [hidden email] <mailto:[hidden email]>
>             http://blog.nanthrax.net
>             Talend - http://www.talend.com
>
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

[Brad Johnson]

I just need to take the time to use the proper BOM and mechanics.  I was trying to shortcut this by having the plugin run on my bundles and create features files for them and then use those features in the assembly.  That was a real long shot because I'm using some older code and tied into a Fuse BOM.  That it didn't just work isn't surprising.  If I chop my dependencies down to just this it zips fine.  If I put the standard features in it gives an error.  But that is likely due to my project hierarchy and the items I use in the parent POM.

 Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.0.5:assembly (process-resources) on project paypal-app: Unable to build assembly: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=feature; type=karaf.feature; version=4.0.5; filter:="(&(osgi.identity=feature)(type=karaf.feature)(version>=4.0.5))" [caused by: Unable to resolve feature/4.0.5: missing requirement [feature/4.0.5] osgi.identity; osgi.identity=org.apache.karaf.features.core; type=osgi.bundle; version="[4.0.5,4.0.5]"; resolution:=mandatory [caused by: Unable to resolve org.apache.karaf.features.core/4.0.5: missing requirement [org.apache.karaf.features.core/4.0.5] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.ops4j.pax.url.mvn)(version>=2.4.0)(!(version>=3.0.0)))"]] -> [Help 1]
[ERROR]

 <dependencies>
        <dependency>
            <groupId>org.apache.karaf.features</groupId>
            <artifactId>static</artifactId>
            <type>kar</type>
            <version>${karaf.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.karaf.features</groupId>
            <artifactId>static</artifactId>
            <classifier>features</classifier>
            <type>xml</type>
            <scope>compile</scope>
            <version>${karaf.version}</version>
        </dependency>
       <!--  <dependency>
            <groupId>org.apache.karaf.features</groupId>
            <artifactId>standard</artifactId>
            <classifier>features</classifier>
            <type>xml</type>
            <scope>compile</scope>
            <version>${karaf.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.karaf.features</groupId>
            <artifactId>enterprise</artifactId>
            <classifier>features</classifier>
            <type>xml</type>
            <scope>compile</scope>
            <version>${karaf.version}</version>
        </dependency> -->
<!--         <dependency>
            <groupId>com.foo.my</groupId>
            <artifactId>features</artifactId>
            <classifier>features</classifier>
            <type>xml</type>
            <scope>compile</scope>
            <version>${project.version}</version>
        </dependency> -->
    </dependencies>

On Thu, Apr 28, 2016 at 10:00 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

Do you have framework and log <feature/> defined in your pom.xml ?

Regards
JB

On 04/28/2016 04:42 PM, Brad Johnson wrote:

  <feature prerequisite="true" dependency="false">wrap</feature>

That's the only issue it is barfing on right now.  I'll just have to run
it down.

[ERROR] Failed to execute goal
org.apache.karaf.tooling:karaf-maven-plugin:4.0.5:assembly
(process-resources) on project paypal-app: Unable to build assembly:
Unable to resolve root: missing requirement [root] osgi.identity;
osgi.identity=wrap; type=karaf.feature; version=0;
filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
[caused by: Unable to resolve wrap/0.0.0: missing requirement
[wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap;
type=osgi.bundle; version="[2.4.7,2.4.7]"; resolution:=mandatory [caused
by: Unable to resolve org.ops4j.pax.url.wrap/2.4.7: missing requirement
[org.ops4j.pax.url.wrap/2.4.7] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
-> [Help 1]
[ERROR]

On Thu, Apr 28, 2016 at 9:30 AM, Brad Johnson
<[hidden email] <mailto:[hidden email]>> wrote:

    Christian,

    Finally got a few minutes breathing room yesterday to work with some
    of the new plugins.  I like the karaf-maven-plugin and the features
    generation.  I'm not sure how much it is pulling that is absolutely
    necessary and how much it is getting as just a scrape.  It doesn't
    seem to differentiate on the test scope. Those are obviously not
    items I'd want in my features file.

    The karaf assembly kicks off fine but of course when I try to use it
    with any of my existing projects I quickly run into a problem that
    my current projects uses Fuse specific items and I'll have to switch
    my BOM to make it work with the assembly.  I'll do that if I get
    some time today.

    The assembly kicks off fine and pulls the karaf instance and begins
    but as soon as it runs into my features file it pukes on some of the
    dependencies. So the best bet would be to use the karaf-plugin and
    let it generate the features file for all my projects and then use
    those in the startup.

    I'll give it a shot today and see what happens.

    Brad

    On Wed, Apr 27, 2016 at 8:51 AM, Brad Johnson
    <[hidden email] <mailto:[hidden email]>>

    wrote:

        JB,

        That's why I haven't had a chance to work with it yet since I'm
        working in Fuse exclusively and it is still on karaf 2.x.  So
        there hasn't been a chance to work with karaf 4 yet other than
        very basic stuff of running it.  But with the static profiles
        doing a proof of concept and self-contained prototype for demo
        and testing means that working with karaf 4 isn't out of line.
        It's one of the issues I have with Fuse is that I'm always a
        step behind the world.  Although it does seem like Karaf 3 was
        sort of brief resting spot on the way to karaf 4 anyway.

        So karaf-boot is leveraging the static profiles and using
        annotations to hook into that? I really think we may be in a
        back to the future situation with karaf.  Ten years ago virtual
        machines as appliances were a new rage.  Now they are rather
        common place.  Docker is an extension and a slimming of that in
        a way.  But karaf as appliances could really be an amazing
        market.  With the amazing goodness of OSGi and the karaf shell
        and being able to SSH in to a container for management that's
        pretty interesting stuff.  A whole different level of
        abstraction opens itself up.

        I think as much out of releasing the mind from concerns as
        anything.  That's true when we started with OO and components
        and services and true at the appliance level as well.  When  you
        can look at an abstraction as a stand alone that can take care
        of its own needs you don't have to juggle it in your head.

        The other day I'd mentioned a gateway appliance I'd like.  Feed
        it an appropriately decorated API interface and it creates
        server endpoints for incoming connections and makes client
        connections inward.  But one could also have appliances for
        isolating databases behind web services.  What the appliance
        makes possible is that physical and mental isolation where I
        just count on the service and don't have to think about how it
        co-exists in the same container with my other OSGi bundles.
        While we all work hard to make sure our exports and private
        packages are kept properly in their place in their bundles not
        every craftsman is equal in skill.  And we all make mistakes.
        Karaf as an appliance mitigates that somewhat.  If the young,
        bright developer I work with doesn't quite get the private
        package right and ends up with his bundle's contents exported to
        the world, well, if he's just exposing web services to isolate a
        database from the world then it isn't as serious a problem.

        Things like Drools rules engines with routes on JMS, SOAP, REST
        coming into it with a highly constrained set of rules for domain
        specific problem also become nifty little appliances.  And so
        many of those have a nice fill in the logic feel to them.  By
        that I mean that 90% of the Maven and profiles are the same.
        You just take the appliance outline and start working with the
        Camel, Java beans, and logic only.

        And testing! By God testing!

        Ahem. I don't know how many hours I've lost on
        CamelBlueprintTestSupport, PaxExam, and so on.  If I can button
        up a nice appliance and simply run some JUnit tests with web
        services on a black box I'm a happy camper.  One thing I've done
        in some of my tests environments that would work well with such
        black box appliances is put endpoint test simulator/stubs right
        in the bundles that are enabled/disabled by configuration
        flags.  One project I'm on right now provides a set of services
        for the enterprise to get things like Invoices.  Those REST and
        SOAP services use canonical models that have Dozer transforms to
        JDE models and a connection to JDE BSSVs (SOAP).  During testing
        I set the flag and instead of using an OSGi service to talk
        directly to JDE it uses a different OSGi service that simply
        serves up dummy data from a map of XStream data models that I
        keep tucked away inside.  But it let's me exercise all the
        routes, transforms, logic and deploy it early on for web tier
        folks to work against.  With the static mechanics I can make an
        appliance of that and switch from test data to actual JDE with
        the flick of a configuration file setting.  Or exercise it from
        my simple JUnit tests.  And Jenkins should be simpler too.

        So yeah, this excites me a great deal.

        Brad

        On Wed, Apr 27, 2016 at 2:26 AM, Jean-Baptiste Onofré

        <[hidden email] <mailto:[hidden email]>> wrote:

            I don't think Karaf is a lot easier: it's a different
            approach, different topology. It's not the same use
            case/packaging.

            It's exactly what karaf-boot is addressing: you use the
            annotations, we deal with the packaging (you just define
            what you want).

            FYI, the static profile exists since 4.0.0 (it came with
            Karaf 4 and profile introduction) ;)

            Regards
            JB


            On 04/27/2016 09:08 AM, Christian Schneider wrote:

                I used the static profile here:
                https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app

                It allows to package a very slim karaf with your
                features. All bundles
                are directly referenced in the startup.properties. So
                there is no need
                for a feature service if your bundles are fixed.
                This makes karaf a lot easier to manage as you typically
                will not have
                refresh issues.

                The nice thing is that you can develop your application
                with normal
                features and decide about the packaging at a very late
                state.

                Christian

                On <a href="tel:26.04.2016%2023" value="[phone]" target="_blank">26.04.2016 23 <tel:26.04.2016%2023>:36, Brad Johnson
                wrote:

                    I looked at the profiles and static and find it
                    interesting.  I'll
                    have to work with it some.  There's obviously a bit
                    of a mind shift
                    there with the inheritance hierarchy.  In my mind's
                    eye I saw this as
                    something I'd run from a parent pom with a bunch of
                    child bundle
                    projects but it would likely be better as an aside
                    project separate
                    from the main build hierarchy itself. Which is
                    fine.  Decouples it as
                    a separate concern.  Just a bit different than I'd
                    imagined.

                    I'll have to give it a swing.



            --
            Jean-Baptiste Onofré
            [hidden email] <mailto:[hidden email]>
            http://blog.nanthrax.net
            Talend - http://www.talend.com

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

[Jean-Baptiste Onofré]

Hi Brad,

can you share the complete pom.xml ? I will help to fix it.

Thanks,
Regards
JB

On 04/28/2016 05:29 PM, Brad Johnson wrote:

> I just need to take the time to use the proper BOM and mechanics.  I was
> trying to shortcut this by having the plugin run on my bundles and
> create features files for them and then use those features in the
> assembly.  That was a real long shot because I'm using some older code
> and tied into a Fuse BOM.  That it didn't just work isn't surprising.
> If I chop my dependencies down to just this it zips fine.  If I put the
> standard features in it gives an error.  But that is likely due to my
> project hierarchy and the items I use in the parent POM.
>
>   Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.5:assembly
> (process-resources) on project paypal-app: Unable to build assembly:
> Unable to resolve root: missing requirement [root] osgi.identity;
> osgi.identity=feature; type=karaf.feature; version=4.0.5;
> filter:="(&(osgi.identity=feature)(type=karaf.feature)(version>=4.0.5))"
> [caused by: Unable to resolve feature/4.0.5: missing requirement
> [feature/4.0.5] osgi.identity;
> osgi.identity=org.apache.karaf.features.core; type=osgi.bundle;
> version="[4.0.5,4.0.5]"; resolution:=mandatory [caused by: Unable to
> resolve org.apache.karaf.features.core/4.0.5: missing requirement
> [org.apache.karaf.features.core/4.0.5] osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.ops4j.pax.url.mvn)(version>=2.4.0)(!(version>=3.0.0)))"]]
> -> [Help 1]
> [ERROR]
>
>   <dependencies>
>          <dependency>
>              <groupId>org.apache.karaf.features</groupId>
>              <artifactId>static</artifactId>
>              <type>kar</type>
>              <version>${karaf.version}</version>
>          </dependency>
>          <dependency>
>              <groupId>org.apache.karaf.features</groupId>
>              <artifactId>static</artifactId>
>              <classifier>features</classifier>
>              <type>xml</type>
>              <scope>compile</scope>
>              <version>${karaf.version}</version>
>          </dependency>
>         <!--  <dependency>
>              <groupId>org.apache.karaf.features</groupId>
>              <artifactId>standard</artifactId>
>              <classifier>features</classifier>
>              <type>xml</type>
>              <scope>compile</scope>
>              <version>${karaf.version}</version>
>          </dependency>
>          <dependency>
>              <groupId>org.apache.karaf.features</groupId>
>              <artifactId>enterprise</artifactId>
>              <classifier>features</classifier>
>              <type>xml</type>
>              <scope>compile</scope>
>              <version>${karaf.version}</version>
>          </dependency> -->
> <!--         <dependency>
>              <groupId>com.foo.my <http://com.foo.my></groupId>
>              <artifactId>features</artifactId>
>              <classifier>features</classifier>
>              <type>xml</type>
>              <scope>compile</scope>
>              <version>${project.version}</version>
>          </dependency> -->
>      </dependencies>
>
> On Thu, Apr 28, 2016 at 10:00 AM, Jean-Baptiste Onofré <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Do you have framework and log <feature/> defined in your pom.xml ?
>
>     Regards
>     JB
>
>     On 04/28/2016 04:42 PM, Brad Johnson wrote:
>
>            <feature prerequisite="true" dependency="false">wrap</feature>
>
>         That's the only issue it is barfing on right now.  I'll just
>         have to run
>         it down.
>
>         [ERROR] Failed to execute goal
>         org.apache.karaf.tooling:karaf-maven-plugin:4.0.5:assembly
>         (process-resources) on project paypal-app: Unable to build assembly:
>         Unable to resolve root: missing requirement [root] osgi.identity;
>         osgi.identity=wrap; type=karaf.feature; version=0;
>         filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
>         [caused by: Unable to resolve wrap/0.0.0: missing requirement
>         [wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap;
>         type=osgi.bundle; version="[2.4.7,2.4.7]"; resolution:=mandatory
>         [caused
>         by: Unable to resolve org.ops4j.pax.url.wrap/2.4.7: missing
>         requirement
>         [org.ops4j.pax.url.wrap/2.4.7] osgi.wiring.package;
>         filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
>         -> [Help 1]
>         [ERROR]
>
>         On Thu, Apr 28, 2016 at 9:30 AM, Brad Johnson
>         <[hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>> wrote:
>
>              Christian,
>
>              Finally got a few minutes breathing room yesterday to work
>         with some
>              of the new plugins.  I like the karaf-maven-plugin and the
>         features
>              generation.  I'm not sure how much it is pulling that is
>         absolutely
>              necessary and how much it is getting as just a scrape.  It
>         doesn't
>              seem to differentiate on the test scope. Those are
>         obviously not
>              items I'd want in my features file.
>
>              The karaf assembly kicks off fine but of course when I try
>         to use it
>              with any of my existing projects I quickly run into a
>         problem that
>              my current projects uses Fuse specific items and I'll have
>         to switch
>              my BOM to make it work with the assembly.  I'll do that if
>         I get
>              some time today.
>
>              The assembly kicks off fine and pulls the karaf instance
>         and begins
>              but as soon as it runs into my features file it pukes on
>         some of the
>              dependencies. So the best bet would be to use the
>         karaf-plugin and
>              let it generate the features file for all my projects and
>         then use
>              those in the startup.
>
>              I'll give it a shot today and see what happens.
>
>              Brad
>
>              On Wed, Apr 27, 2016 at 8:51 AM, Brad Johnson
>              <[hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>
>              wrote:
>
>                  JB,
>
>                  That's why I haven't had a chance to work with it yet
>         since I'm
>                  working in Fuse exclusively and it is still on karaf
>         2.x.  So
>                  there hasn't been a chance to work with karaf 4 yet
>         other than
>                  very basic stuff of running it.  But with the static
>         profiles
>                  doing a proof of concept and self-contained prototype
>         for demo
>                  and testing means that working with karaf 4 isn't out
>         of line.
>                  It's one of the issues I have with Fuse is that I'm
>         always a
>                  step behind the world.  Although it does seem like
>         Karaf 3 was
>                  sort of brief resting spot on the way to karaf 4 anyway.
>
>                  So karaf-boot is leveraging the static profiles and using
>                  annotations to hook into that? I really think we may be
>         in a
>                  back to the future situation with karaf.  Ten years ago
>         virtual
>                  machines as appliances were a new rage.  Now they are
>         rather
>                  common place.  Docker is an extension and a slimming of
>         that in
>                  a way.  But karaf as appliances could really be an amazing
>                  market.  With the amazing goodness of OSGi and the
>         karaf shell
>                  and being able to SSH in to a container for management
>         that's
>                  pretty interesting stuff.  A whole different level of
>                  abstraction opens itself up.
>
>                  I think as much out of releasing the mind from concerns as
>                  anything.  That's true when we started with OO and
>         components
>                  and services and true at the appliance level as well.
>         When  you
>                  can look at an abstraction as a stand alone that can
>         take care
>                  of its own needs you don't have to juggle it in your head.
>
>                  The other day I'd mentioned a gateway appliance I'd
>         like.  Feed
>                  it an appropriately decorated API interface and it creates
>                  server endpoints for incoming connections and makes client
>                  connections inward.  But one could also have appliances for
>                  isolating databases behind web services.  What the
>         appliance
>                  makes possible is that physical and mental isolation
>         where I
>                  just count on the service and don't have to think about
>         how it
>                  co-exists in the same container with my other OSGi bundles.
>                  While we all work hard to make sure our exports and private
>                  packages are kept properly in their place in their
>         bundles not
>                  every craftsman is equal in skill.  And we all make
>         mistakes.
>                  Karaf as an appliance mitigates that somewhat.  If the
>         young,
>                  bright developer I work with doesn't quite get the private
>                  package right and ends up with his bundle's contents
>         exported to
>                  the world, well, if he's just exposing web services to
>         isolate a
>                  database from the world then it isn't as serious a problem.
>
>                  Things like Drools rules engines with routes on JMS,
>         SOAP, REST
>                  coming into it with a highly constrained set of rules
>         for domain
>                  specific problem also become nifty little appliances.
>         And so
>                  many of those have a nice fill in the logic feel to
>         them.  By
>                  that I mean that 90% of the Maven and profiles are the
>         same.
>                  You just take the appliance outline and start working
>         with the
>                  Camel, Java beans, and logic only.
>
>                  And testing! By God testing!
>
>                  Ahem. I don't know how many hours I've lost on
>                  CamelBlueprintTestSupport, PaxExam, and so on.  If I
>         can button
>                  up a nice appliance and simply run some JUnit tests
>         with web
>                  services on a black box I'm a happy camper.  One thing
>         I've done
>                  in some of my tests environments that would work well
>         with such
>                  black box appliances is put endpoint test
>         simulator/stubs right
>                  in the bundles that are enabled/disabled by configuration
>                  flags.  One project I'm on right now provides a set of
>         services
>                  for the enterprise to get things like Invoices.  Those
>         REST and
>                  SOAP services use canonical models that have Dozer
>         transforms to
>                  JDE models and a connection to JDE BSSVs (SOAP).
>         During testing
>                  I set the flag and instead of using an OSGi service to talk
>                  directly to JDE it uses a different OSGi service that
>         simply
>                  serves up dummy data from a map of XStream data models
>         that I
>                  keep tucked away inside.  But it let's me exercise all the
>                  routes, transforms, logic and deploy it early on for
>         web tier
>                  folks to work against.  With the static mechanics I can
>         make an
>                  appliance of that and switch from test data to actual
>         JDE with
>                  the flick of a configuration file setting.  Or exercise
>         it from
>                  my simple JUnit tests.  And Jenkins should be simpler too.
>
>                  So yeah, this excites me a great deal.
>
>                  Brad
>
>                  On Wed, Apr 27, 2016 at 2:26 AM, Jean-Baptiste Onofré
>                  <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>
>                      I don't think Karaf is a lot easier: it's a different
>                      approach, different topology. It's not the same use
>                      case/packaging.
>
>                      It's exactly what karaf-boot is addressing: you use the
>                      annotations, we deal with the packaging (you just
>         define
>                      what you want).
>
>                      FYI, the static profile exists since 4.0.0 (it came
>         with
>                      Karaf 4 and profile introduction) ;)
>
>                      Regards
>                      JB
>
>
>                      On 04/27/2016 09:08 AM, Christian Schneider wrote:
>
>                          I used the static profile here:
>         https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app
>
>                          It allows to package a very slim karaf with your
>                          features. All bundles
>                          are directly referenced in the
>         startup.properties. So
>                          there is no need
>                          for a feature service if your bundles are fixed.
>                          This makes karaf a lot easier to manage as you
>         typically
>                          will not have
>                          refresh issues.
>
>                          The nice thing is that you can develop your
>         application
>                          with normal
>                          features and decide about the packaging at a
>         very late
>                          state.
>
>                          Christian
>
>                          On 26.04.2016 23 <tel:26.04.2016%2023>
>         <tel:26.04.2016%2023>:36, Brad Johnson
>                          wrote:
>
>                              I looked at the profiles and static and find it
>                              interesting.  I'll
>                              have to work with it some.  There's
>         obviously a bit
>                              of a mind shift
>                              there with the inheritance hierarchy.  In
>         my mind's
>                              eye I saw this as
>                              something I'd run from a parent pom with a
>         bunch of
>                              child bundle
>                              projects but it would likely be better as
>         an aside
>                              project separate
>                              from the main build hierarchy itself. Which is
>                              fine.  Decouples it as
>                              a separate concern.  Just a bit different
>         than I'd
>                              imagined.
>
>                              I'll have to give it a swing.
>
>
>
>                      --
>                      Jean-Baptiste Onofré
>         [hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>         http://blog.nanthrax.net
>                      Talend - http://www.talend.com
>
>
>
>
>
>     --
>     Jean-Baptiste Onofré
>     [hidden email] <mailto:[hidden email]>
>     http://blog.nanthrax.net
>     Talend - http://www.talend.com
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

[Brad Johnson]

JB,

I'll take you up on that when I have a better idea of what I'm doing with it.  I work with features in Fuse all the time but I'm not sure of the static mechanics and so was just taking baby steps.  When I hit a spot that obviously was my bad I stopped and had to rethink how to approach this.  Probably download your full example and pare it back.  For example, the following very simple POM taken from Christians sample will pull everything fine and zip up until I add in the standard or enterprise features.  That's probably because I'm missing other dependency information or plugins.  That's not really something I can expect you to help me with as I'm obviously misusing/abusing the idea.


 

    <groupId>com.foo.bar</groupId>
    <artifactId>foo-app</artifactId>
    <version>1.0.1-SNAPSHOT</version>


    <packaging>pom</packaging>

    <properties>
        <karaf.version>4.0.5</karaf.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.apache.karaf.features</groupId>
            <artifactId>static</artifactId>
            <type>kar</type>
            <version>${karaf.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.karaf.features</groupId>
            <artifactId>static</artifactId>
            <classifier>features</classifier>
            <type>xml</type>
            <scope>compile</scope>
            <version>${karaf.version}</version>
        </dependency>

//If I add either of these then I start getting errors which I'm going to guess is because I'm missing necessary dependencies.

//or configuration data.

        <!-- <dependency> <groupId>org.apache.karaf.features</groupId> <artifactId>standard</artifactId>
            <classifier>features</classifier> <type>xml</type> <scope>compile</scope>
            <version>${karaf.version}</version> </dependency> <dependency> <groupId>org.apache.karaf.features</groupId>
            <artifactId>enterprise</artifactId> <classifier>features</classifier> <type>xml</type>
            <scope>compile</scope> <version>${karaf.version}</version> </dependency> -->
        <!-- <dependency> <groupId>com.svm.esb.payments</groupId> <artifactId>features</artifactId>
            <classifier>features</classifier> <type>xml</type> <scope>compile</scope>
            <version>${project.version}</version> </dependency> -->
    </dependencies>
    <build>
        <resources>
            <resource>
                <directory>src/main/resources</directory>
            </resource>
        </resources>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-resources-plugin</artifactId>
                <executions>
                    <execution>
                        <id>process-resources</id>
                        <goals>
                            <goal>resources</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.karaf.tooling</groupId>
                <artifactId>karaf-maven-plugin</artifactId>
                <version>${karaf.version}</version>
                <executions>
                    <execution>
                        <id>process-resources</id>
                        <phase>process-resources</phase>
                        <goals>
                            <goal>assembly</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>package</id>
                        <goals>
                            <goal>archive</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <javase>1.8</javase>
                    <startupFeatures>

//Not even attempting this yet.

                    </startupFeatures>
                </configuration>
            </plugin>

        </plugins>
    </build>

On Thu, Apr 28, 2016 at 10:32 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

Hi Brad,

can you share the complete pom.xml ? I will help to fix it.

Thanks,
Regards
JB

On 04/28/2016 05:29 PM, Brad Johnson wrote:

I just need to take the time to use the proper BOM and mechanics.  I was
trying to shortcut this by having the plugin run on my bundles and
create features files for them and then use those features in the
assembly.  That was a real long shot because I'm using some older code
and tied into a Fuse BOM.  That it didn't just work isn't surprising.
If I chop my dependencies down to just this it zips fine.  If I put the
standard features in it gives an error.  But that is likely due to my
project hierarchy and the items I use in the parent POM.

  Failed to execute goal
org.apache.karaf.tooling:karaf-maven-plugin:4.0.5:assembly
(process-resources) on project paypal-app: Unable to build assembly:
Unable to resolve root: missing requirement [root] osgi.identity;
osgi.identity=feature; type=karaf.feature; version=4.0.5;
filter:="(&(osgi.identity=feature)(type=karaf.feature)(version>=4.0.5))"
[caused by: Unable to resolve feature/4.0.5: missing requirement
[feature/4.0.5] osgi.identity;
osgi.identity=org.apache.karaf.features.core; type=osgi.bundle;
version="[4.0.5,4.0.5]"; resolution:=mandatory [caused by: Unable to
resolve org.apache.karaf.features.core/4.0.5: missing requirement
[org.apache.karaf.features.core/4.0.5] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.ops4j.pax.url.mvn)(version>=2.4.0)(!(version>=3.0.0)))"]]
-> [Help 1]
[ERROR]

  <dependencies>
         <dependency>
             <groupId>org.apache.karaf.features</groupId>
             <artifactId>static</artifactId>
             <type>kar</type>
             <version>${karaf.version}</version>
         </dependency>
         <dependency>
             <groupId>org.apache.karaf.features</groupId>
             <artifactId>static</artifactId>
             <classifier>features</classifier>
             <type>xml</type>
             <scope>compile</scope>
             <version>${karaf.version}</version>
         </dependency>
        <!--  <dependency>
             <groupId>org.apache.karaf.features</groupId>
             <artifactId>standard</artifactId>
             <classifier>features</classifier>
             <type>xml</type>
             <scope>compile</scope>
             <version>${karaf.version}</version>
         </dependency>
         <dependency>
             <groupId>org.apache.karaf.features</groupId>
             <artifactId>enterprise</artifactId>
             <classifier>features</classifier>
             <type>xml</type>
             <scope>compile</scope>
             <version>${karaf.version}</version>
         </dependency> -->
<!--         <dependency>

             <groupId>com.foo.my <http://com.foo.my></groupId>
             <artifactId>features</artifactId>
             <classifier>features</classifier>
             <type>xml</type>
             <scope>compile</scope>
             <version>${project.version}</version>
         </dependency> -->
     </dependencies>

On Thu, Apr 28, 2016 at 10:00 AM, Jean-Baptiste Onofré <[hidden email]

<mailto:[hidden email]>> wrote:

    Do you have framework and log <feature/> defined in your pom.xml ?

    Regards
    JB

    On 04/28/2016 04:42 PM, Brad Johnson wrote:

           <feature prerequisite="true" dependency="false">wrap</feature>

        That's the only issue it is barfing on right now.  I'll just
        have to run
        it down.

        [ERROR] Failed to execute goal
        org.apache.karaf.tooling:karaf-maven-plugin:4.0.5:assembly
        (process-resources) on project paypal-app: Unable to build assembly:
        Unable to resolve root: missing requirement [root] osgi.identity;
        osgi.identity=wrap; type=karaf.feature; version=0;
        filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))"
        [caused by: Unable to resolve wrap/0.0.0: missing requirement
        [wrap/0.0.0] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap;
        type=osgi.bundle; version="[2.4.7,2.4.7]"; resolution:=mandatory
        [caused
        by: Unable to resolve org.ops4j.pax.url.wrap/2.4.7: missing
        requirement
        [org.ops4j.pax.url.wrap/2.4.7] osgi.wiring.package;
        filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
        -> [Help 1]
        [ERROR]

        On Thu, Apr 28, 2016 at 9:30 AM, Brad Johnson
        <[hidden email]
        <mailto:[hidden email]>

        <mailto:[hidden email]

        <mailto:[hidden email]>>> wrote:

             Christian,

             Finally got a few minutes breathing room yesterday to work
        with some
             of the new plugins.  I like the karaf-maven-plugin and the
        features
             generation.  I'm not sure how much it is pulling that is
        absolutely
             necessary and how much it is getting as just a scrape.  It
        doesn't
             seem to differentiate on the test scope. Those are
        obviously not
             items I'd want in my features file.

             The karaf assembly kicks off fine but of course when I try
        to use it
             with any of my existing projects I quickly run into a
        problem that
             my current projects uses Fuse specific items and I'll have
        to switch
             my BOM to make it work with the assembly.  I'll do that if
        I get
             some time today.

             The assembly kicks off fine and pulls the karaf instance
        and begins
             but as soon as it runs into my features file it pukes on
        some of the
             dependencies. So the best bet would be to use the
        karaf-plugin and
             let it generate the features file for all my projects and
        then use
             those in the startup.

             I'll give it a shot today and see what happens.

             Brad

             On Wed, Apr 27, 2016 at 8:51 AM, Brad Johnson
             <[hidden email]
        <mailto:[hidden email]>

        <mailto:[hidden email]

        <mailto:[hidden email]>>>

             wrote:

                 JB,

                 That's why I haven't had a chance to work with it yet
        since I'm
                 working in Fuse exclusively and it is still on karaf
        2.x.  So
                 there hasn't been a chance to work with karaf 4 yet
        other than
                 very basic stuff of running it.  But with the static
        profiles
                 doing a proof of concept and self-contained prototype
        for demo
                 and testing means that working with karaf 4 isn't out
        of line.
                 It's one of the issues I have with Fuse is that I'm
        always a
                 step behind the world.  Although it does seem like
        Karaf 3 was
                 sort of brief resting spot on the way to karaf 4 anyway.

                 So karaf-boot is leveraging the static profiles and using
                 annotations to hook into that? I really think we may be
        in a
                 back to the future situation with karaf.  Ten years ago
        virtual
                 machines as appliances were a new rage.  Now they are
        rather
                 common place.  Docker is an extension and a slimming of
        that in
                 a way.  But karaf as appliances could really be an amazing
                 market.  With the amazing goodness of OSGi and the
        karaf shell
                 and being able to SSH in to a container for management
        that's
                 pretty interesting stuff.  A whole different level of
                 abstraction opens itself up.

                 I think as much out of releasing the mind from concerns as
                 anything.  That's true when we started with OO and
        components
                 and services and true at the appliance level as well.
        When  you
                 can look at an abstraction as a stand alone that can
        take care
                 of its own needs you don't have to juggle it in your head.

                 The other day I'd mentioned a gateway appliance I'd
        like.  Feed
                 it an appropriately decorated API interface and it creates
                 server endpoints for incoming connections and makes client
                 connections inward.  But one could also have appliances for
                 isolating databases behind web services.  What the
        appliance
                 makes possible is that physical and mental isolation
        where I
                 just count on the service and don't have to think about
        how it
                 co-exists in the same container with my other OSGi bundles.
                 While we all work hard to make sure our exports and private
                 packages are kept properly in their place in their
        bundles not
                 every craftsman is equal in skill.  And we all make
        mistakes.
                 Karaf as an appliance mitigates that somewhat.  If the
        young,
                 bright developer I work with doesn't quite get the private
                 package right and ends up with his bundle's contents
        exported to
                 the world, well, if he's just exposing web services to
        isolate a
                 database from the world then it isn't as serious a problem.

                 Things like Drools rules engines with routes on JMS,
        SOAP, REST
                 coming into it with a highly constrained set of rules
        for domain
                 specific problem also become nifty little appliances.
        And so
                 many of those have a nice fill in the logic feel to
        them.  By
                 that I mean that 90% of the Maven and profiles are the
        same.
                 You just take the appliance outline and start working
        with the
                 Camel, Java beans, and logic only.

                 And testing! By God testing!

                 Ahem. I don't know how many hours I've lost on
                 CamelBlueprintTestSupport, PaxExam, and so on.  If I
        can button
                 up a nice appliance and simply run some JUnit tests
        with web
                 services on a black box I'm a happy camper.  One thing
        I've done
                 in some of my tests environments that would work well
        with such
                 black box appliances is put endpoint test
        simulator/stubs right
                 in the bundles that are enabled/disabled by configuration
                 flags.  One project I'm on right now provides a set of
        services
                 for the enterprise to get things like Invoices.  Those
        REST and
                 SOAP services use canonical models that have Dozer
        transforms to
                 JDE models and a connection to JDE BSSVs (SOAP).
        During testing
                 I set the flag and instead of using an OSGi service to talk
                 directly to JDE it uses a different OSGi service that
        simply
                 serves up dummy data from a map of XStream data models
        that I
                 keep tucked away inside.  But it let's me exercise all the
                 routes, transforms, logic and deploy it early on for
        web tier
                 folks to work against.  With the static mechanics I can
        make an
                 appliance of that and switch from test data to actual
        JDE with
                 the flick of a configuration file setting.  Or exercise
        it from
                 my simple JUnit tests.  And Jenkins should be simpler too.

                 So yeah, this excites me a great deal.

                 Brad

                 On Wed, Apr 27, 2016 at 2:26 AM, Jean-Baptiste Onofré
                 <[hidden email] <mailto:[hidden email]>

        <mailto:[hidden email] <mailto:[hidden email]>>> wrote:

                     I don't think Karaf is a lot easier: it's a different
                     approach, different topology. It's not the same use
                     case/packaging.

                     It's exactly what karaf-boot is addressing: you use the
                     annotations, we deal with the packaging (you just
        define
                     what you want).

                     FYI, the static profile exists since 4.0.0 (it came
        with
                     Karaf 4 and profile introduction) ;)

                     Regards
                     JB


                     On 04/27/2016 09:08 AM, Christian Schneider wrote:

                         I used the static profile here:
        https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app

                         It allows to package a very slim karaf with your
                         features. All bundles
                         are directly referenced in the
        startup.properties. So
                         there is no need
                         for a feature service if your bundles are fixed.
                         This makes karaf a lot easier to manage as you
        typically
                         will not have
                         refresh issues.

                         The nice thing is that you can develop your
        application
                         with normal
                         features and decide about the packaging at a
        very late
                         state.

                         Christian

                         On <a href="tel:26.04.2016%2023" value="[phone]" target="_blank">26.04.2016 23 <tel:26.04.2016%2023>
        <tel:26.04.2016%2023>:36, Brad Johnson
                         wrote:

                             I looked at the profiles and static and find it
                             interesting.  I'll
                             have to work with it some.  There's
        obviously a bit
                             of a mind shift
                             there with the inheritance hierarchy.  In
        my mind's
                             eye I saw this as
                             something I'd run from a parent pom with a
        bunch of
                             child bundle
                             projects but it would likely be better as
        an aside
                             project separate
                             from the main build hierarchy itself. Which is
                             fine.  Decouples it as
                             a separate concern.  Just a bit different
        than I'd
                             imagined.

                             I'll have to give it a swing.



                     --
                     Jean-Baptiste Onofré
        [hidden email] <mailto:[hidden email]>

        <mailto:[hidden email] <mailto:[hidden email]>>
        http://blog.nanthrax.net
                     Talend - http://www.talend.com





    --
    Jean-Baptiste Onofré
    [hidden email] <mailto:[hidden email]>
    http://blog.nanthrax.net
    Talend - http://www.talend.com

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com