Deploying applications on Karaf

[Ryan Moquin <fr...@gmail.com>]

Hi,

I have another question regarding Karaf and deployments.  I was hoping
maybe some others could chime in on how they deal with the following
situation.

I've been working on a fairly complex Karaf based application.  I'm using
features heavily to allow deploying the correct resources in different
environments (configuration and bundles).  I find it works very well except
for a couple situations:

1.  Unit testing.  It's hard to unit test things like camel routes since I
have ended up basically marking all bundle dependencies as provided (in
order to keep the created features files .  So if I try to unit test a
Camel route, transitive dependencies have to be directly added to the
project pom.

2.  I have all my configurations defined in a maven project for assembling
the final features xml file.  This of course doesn't make it easy to use
any of those configurations in camel integration tests since configurations
needed for config admin would have to be added to the projects test
resources.

Obviously the two brief examples above focus mostly on Camel, but the main
problem is that I'm trying to figure out how I can no longer make
everything provided in my bundle project provided scope without having to
manually maintain the features files.

That being said, I was looking at Apache Ace, but I'm not sure if using
Apache Ace would cause it to be more work to do Karaf integration testing
since Apache Ace doesn't use Karaf features.  I thought about maybe using
OBR, but we use Artifactory and so I'm not sure if going down the OBR route
might ultimately not be possible (I could be wrong but Artifactory doesn't
appear to have OBR support), also I read that OSGi has moved away from OBR
to different repository mechanism (forget offhand what it's called).  I
looked into Apache Cave, but I don't want to rock the boat where I'm at yet
since I'm the only one pushing Karaf and OSGi currently.  I don't want to
try to push things out of my organizations comfort zone by getting too
radical in my project deployment.  I haven't gotten to read into the Karaf
4.0 profiles yet.

What it really boils down to is that I'm not sure which deployment approach
with Karaf would be the best to use out of all the options with the goal of
moving to a continuous deployment model.

Hoping someone might be willing to comment on how they solved these issues
or maybe what direction I should look at going down that will allow me to
improve these aspects.  It took me a while to get things where they are at,
I want to be pretty confident in what path I go down next since if it
doesn't pan out, it will be a lot of potentially wasted time and effort. :)

Thanks in advance for any thoughts/suggestions.

Ryan

Re: Deploying applications on Karaf

[Ryan Moquin <fr...@gmail.com>]

They do support P2.. isn't that similar to OBR?  It sucks because we picked
artifactory for our repository.  I figured there had to be a way it could
work as an OBR server.  Disappointing.
On Apr 15, 2015 4:56 PM, "Michael Täschner" <m....@gmail.com> wrote:

> Hi,
>
> >> Not sure if Artifactory can function as an OBR like Nexus still
>
> this reminds me of JFrogs booth at last years JAX (Java Experience
> Convention):
> - "Do you support OBR in Artifactory via plugins or similar?" - "No, we
> don't believe in OSGi!" That about ended our conversation ...
>
> Cheers,
> Michael
>
> 2015-04-15 22:41 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>
>> Thanks Achim.  I think that adding it to your pom with aggregate features
>> set on the plugin will add it to the features xml.
>>
>> Ah, that's right.  That's what I observed and forgot that it matches what
>> you guys said about feature uninstalling.
>>
>> I can't wait to try Karaf 4.
>>
>> I'll get details on it and ask the ops4j guys.
>>
>> I am thinking I should look into utilizing OBR with Karaf.  Not sure if
>> Artifactory can function as an OBR like Nexus still.
>>
>> Thanks!
>>
>> Ryan
>> Hi Ryan,
>>
>> some comments inline
>>
>> regards, Achim
>>
>>
>> 2015-04-13 0:14 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>
>>> Don't get me, features are a ton of help.  :)  I could maintain the
>>> features myself, I just hate to have to keep two lists of dependencies.
>>> The reason that the karaf maven plugin is a little tough sometimes is
>>> because it's hard to make sure that you don't end up with bundles in a
>>> generated feature that should come from a dependent feature without making
>>> everything provided.  Making most of the dependencies provided makes it
>>> hard to have transitive dependencies available in project dependencies
>>> because they are marked provided in the other poms.  There is probably a
>>> better way to handle it that I haven't figured out yet.  My project is
>>> growing rapidly so I am trying to leverage whatever tools I can to keep my
>>> features clean and not have to spend lots of time on them.
>>>
>>> Have you tried to add features as dependencies to your pom. AFAIK those
>> should show up as dependencies in the generated features.xml. If not we
>> just found a new use-case for the maven plugin and you could open an issue
>> for it ;)
>>
>>
>>> One thing I've been wrestling with (not sure if this has been improved
>>> in Karaf 4)
>>> is figuring out how to upgrade features and handle undeploying
>>> features.. I've played around with it but I guess I'm not sure I understand
>>> the proper way to do it.  Such as if you had an application deployed in an
>>> environment and wanted to upgrade a feature, do you have to install the new
>>> features and uninstall the old one?  When I've tried to uninstall a feature
>>> previously, it didn't seem like everything got removed.
>>>
>> Till Karaf 4, you explicitly need to uninstall transitive features
>> because the features installer used to be quite dumb and therefore doesn't
>> know of possible other dependencies on this feature.
>> With Karaf 4 this will improve quite a bit.
>>
>>
>>> I want want to be able to do incremental upgrades of my app but not sure
>>> the best way to achieve that with features.  :)  I've done quite a lot of
>>> research on it but haven't quite narrowed down a concrete way to do it (I
>>> mean beyond manually upgrading individual bundles in the karaf console.)
>>>
>>> Upgrades is still an "open" field, with Karaf 4 I think it will be
>> easier.
>>
>>
>>> Our Bamboo instance has access to the internet.  I think it hangs right
>>> at the beginning of Pax Exam starting up.  It's such a pain to deal with
>>> our Bamboo EC2 instance that I haven't been able to find out why it's
>>> hanging yet.
>>>
>> maybe post this as a question at the OPS4j list with some more details of
>> the logfiles.
>>
>>
>>
>>
>>> Ryan
>>> On Apr 12, 2015 2:34 AM, "Achim Nierbeck" <bc...@googlemail.com>
>>> wrote:
>>>
>>>> Hi Ryan,
>>>>
>>>> see comments inline.
>>>>
>>>> regards, Achim
>>>>
>>>>
>>>> 2015-04-12 0:37 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>>
>>>>> Thanks, Achim.  I am using a custom Karaf distribution, but
>>>>> maintaining deployment flexibility using features feels a little tougher
>>>>> than it feels like it should be (I don't have any better ideas).
>>>>>
>>>> That's strange, cause features are there to make life easier not
>>>> harder. Make sure you cut the features right, not to big but also not to
>>>> small (like one bundle, one feature). Usually it helps to create those
>>>> feature files yourself as the plugin can't estimate what your intension of
>>>> this combination of bundles is.
>>>>
>>>>
>>>>>   I also have issues with my Karaf integration tests in Bamboo.
>>>>> Paxexam seems to not be able to initialize properly for who knows what
>>>>> reason.  Another problem is that I seem to run into a lot of problems in
>>>>> the tests and can't seem to find anything in the output or Karaf love that
>>>>> indicate.the problem.  If I run it normally in Karaf, I usually get clued
>>>>> into what the issue is.
>>>>>
>>>> Now that could be addressed. First of all, does it work for you on your
>>>> machine? Is Bamboo capable of connecting to the internet.
>>>> Is maven capable of connecting to the required repositories. Do you
>>>> have all dependencies defined in your POM, so the configuration section of
>>>> the test does find those (combined with the depends-maven-plugin)
>>>>
>>>>
>>>>> One last thing is that since my development shop uses MacOSx, Docker
>>>>> containers have to be run in a VM which feels silly and is slow.  I don't
>>>>> have a choice in that manner.
>>>>>
>>>> Oh, I'm working with MacOSx too. I know it can be cumbersome but
>>>> running 4 images in parallel can be done :-)
>>>>
>>>>
>>>>
>>>>> It would be nice if there was a way to manage feature xml files in a
>>>>> way that felt more straight forward....  Maybe there is and I'm just not
>>>>> aware of it.
>>>>>
>>>> You have the choices, use the karaf maven plugin for generation, or
>>>> build those yourself. In the end it's up to how you want your application
>>>> build.
>>>> But maybe I miss something cause usually you have a certain set of
>>>> bundles running in your application that need to run anyway. With this
>>>> setup you can test your application.
>>>>
>>>>
>>>>
>>>>> On Apr 8, 2015 3:07 PM, "Achim Nierbeck" <bc...@googlemail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> just recently for a talk with showcase I was thinking about how to
>>>>>> create a CI/CD build pipeline with Karaf. Maybe some of this does help
>>>>>> you.[1]
>>>>>> In the end I ended up with a setup where I have a pre-configured
>>>>>> Karaf (custom build) which is startable as Docker Image or can be used as
>>>>>> startup tar.gz of the Pax Exam integration tests.
>>>>>> Usually camel routes are more about Integration therefore the most
>>>>>> use-cases need to be handled by Integration tests. In those scenarios you
>>>>>> just can't rely only on the camel-core bundles therefore you need more
>>>>>> features just to have your unit tests/integration tests runnable. In those
>>>>>> scenarios I usually suggest build your own distribution on top of Karaf and
>>>>>> use it as your base-image in the pax-exam tests. If there is more external
>>>>>> infrastructure needed I tend to use either full-integration test systems or
>>>>>> now a docker based test-environment which can be started via a maven goal
>>>>>> as pre-intergration phase systems.
>>>>>>
>>>>>> regards, Achim
>>>>>>
>>>>>> [1] - https://github.com/ANierbeck/JavaLang-Tooling
>>>>>>
>>>>>> 2015-04-08 17:24 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have another question regarding Karaf and deployments.  I was
>>>>>>> hoping maybe some others could chime in on how they deal with the following
>>>>>>> situation.
>>>>>>>
>>>>>>> I've been working on a fairly complex Karaf based application.  I'm
>>>>>>> using features heavily to allow deploying the correct resources in
>>>>>>> different environments (configuration and bundles).  I find it works very
>>>>>>> well except for a couple situations:
>>>>>>>
>>>>>>> 1.  Unit testing.  It's hard to unit test things like camel routes
>>>>>>> since I have ended up basically marking all bundle dependencies as provided
>>>>>>> (in order to keep the created features files .  So if I try to unit test a
>>>>>>> Camel route, transitive dependencies have to be directly added to the
>>>>>>> project pom.
>>>>>>>
>>>>>>> 2.  I have all my configurations defined in a maven project for
>>>>>>> assembling the final features xml file.  This of course doesn't make it
>>>>>>> easy to use any of those configurations in camel integration tests since
>>>>>>> configurations needed for config admin would have to be added to the
>>>>>>> projects test resources.
>>>>>>>
>>>>>>> Obviously the two brief examples above focus mostly on Camel, but
>>>>>>> the main problem is that I'm trying to figure out how I can no longer make
>>>>>>> everything provided in my bundle project provided scope without having to
>>>>>>> manually maintain the features files.
>>>>>>>
>>>>>>> That being said, I was looking at Apache Ace, but I'm not sure if
>>>>>>> using Apache Ace would cause it to be more work to do Karaf integration
>>>>>>> testing since Apache Ace doesn't use Karaf features.  I thought about maybe
>>>>>>> using OBR, but we use Artifactory and so I'm not sure if going down the OBR
>>>>>>> route might ultimately not be possible (I could be wrong but Artifactory
>>>>>>> doesn't appear to have OBR support), also I read that OSGi has moved away
>>>>>>> from OBR to different repository mechanism (forget offhand what it's
>>>>>>> called).  I looked into Apache Cave, but I don't want to rock the boat
>>>>>>> where I'm at yet since I'm the only one pushing Karaf and OSGi currently.
>>>>>>> I don't want to try to push things out of my organizations comfort zone by
>>>>>>> getting too radical in my project deployment.  I haven't gotten to read
>>>>>>> into the Karaf 4.0 profiles yet.
>>>>>>>
>>>>>>> What it really boils down to is that I'm not sure which deployment
>>>>>>> approach with Karaf would be the best to use out of all the options with
>>>>>>> the goal of moving to a continuous deployment model.
>>>>>>>
>>>>>>> Hoping someone might be willing to comment on how they solved these
>>>>>>> issues or maybe what direction I should look at going down that will allow
>>>>>>> me to improve these aspects.  It took me a while to get things where they
>>>>>>> are at, I want to be pretty confident in what path I go down next since if
>>>>>>> it doesn't pan out, it will be a lot of potentially wasted time and effort.
>>>>>>> :)
>>>>>>>
>>>>>>> Thanks in advance for any thoughts/suggestions.
>>>>>>>
>>>>>>> Ryan
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Apache Member
>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>> Committer & Project Lead
>>>>>> blog <http://notizblog.nierbeck.de/>
>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>
>>>>>> Software Architect / Project Manager / Scrum Master
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Apache Member
>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>> Committer & Project Lead
>>>> blog <http://notizblog.nierbeck.de/>
>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>
>>>> Software Architect / Project Manager / Scrum Master
>>>>
>>>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>
>

Re: Deploying applications on Karaf

[Michael Täschner <m....@gmail.com>]

Hi,

>> Not sure if Artifactory can function as an OBR like Nexus still

this reminds me of JFrogs booth at last years JAX (Java Experience
Convention):
- "Do you support OBR in Artifactory via plugins or similar?" - "No, we
don't believe in OSGi!" That about ended our conversation ...

Cheers,
Michael

2015-04-15 22:41 GMT+02:00 Ryan Moquin <fr...@gmail.com>:

> Thanks Achim.  I think that adding it to your pom with aggregate features
> set on the plugin will add it to the features xml.
>
> Ah, that's right.  That's what I observed and forgot that it matches what
> you guys said about feature uninstalling.
>
> I can't wait to try Karaf 4.
>
> I'll get details on it and ask the ops4j guys.
>
> I am thinking I should look into utilizing OBR with Karaf.  Not sure if
> Artifactory can function as an OBR like Nexus still.
>
> Thanks!
>
> Ryan
> Hi Ryan,
>
> some comments inline
>
> regards, Achim
>
>
> 2015-04-13 0:14 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>
>> Don't get me, features are a ton of help.  :)  I could maintain the
>> features myself, I just hate to have to keep two lists of dependencies.
>> The reason that the karaf maven plugin is a little tough sometimes is
>> because it's hard to make sure that you don't end up with bundles in a
>> generated feature that should come from a dependent feature without making
>> everything provided.  Making most of the dependencies provided makes it
>> hard to have transitive dependencies available in project dependencies
>> because they are marked provided in the other poms.  There is probably a
>> better way to handle it that I haven't figured out yet.  My project is
>> growing rapidly so I am trying to leverage whatever tools I can to keep my
>> features clean and not have to spend lots of time on them.
>>
>> Have you tried to add features as dependencies to your pom. AFAIK those
> should show up as dependencies in the generated features.xml. If not we
> just found a new use-case for the maven plugin and you could open an issue
> for it ;)
>
>
>> One thing I've been wrestling with (not sure if this has been improved in
>> Karaf 4)
>> is figuring out how to upgrade features and handle undeploying features..
>> I've played around with it but I guess I'm not sure I understand the proper
>> way to do it.  Such as if you had an application deployed in an environment
>> and wanted to upgrade a feature, do you have to install the new features
>> and uninstall the old one?  When I've tried to uninstall a feature
>> previously, it didn't seem like everything got removed.
>>
> Till Karaf 4, you explicitly need to uninstall transitive features because
> the features installer used to be quite dumb and therefore doesn't know of
> possible other dependencies on this feature.
> With Karaf 4 this will improve quite a bit.
>
>
>> I want want to be able to do incremental upgrades of my app but not sure
>> the best way to achieve that with features.  :)  I've done quite a lot of
>> research on it but haven't quite narrowed down a concrete way to do it (I
>> mean beyond manually upgrading individual bundles in the karaf console.)
>>
>> Upgrades is still an "open" field, with Karaf 4 I think it will be
> easier.
>
>
>> Our Bamboo instance has access to the internet.  I think it hangs right
>> at the beginning of Pax Exam starting up.  It's such a pain to deal with
>> our Bamboo EC2 instance that I haven't been able to find out why it's
>> hanging yet.
>>
> maybe post this as a question at the OPS4j list with some more details of
> the logfiles.
>
>
>
>
>> Ryan
>> On Apr 12, 2015 2:34 AM, "Achim Nierbeck" <bc...@googlemail.com>
>> wrote:
>>
>>> Hi Ryan,
>>>
>>> see comments inline.
>>>
>>> regards, Achim
>>>
>>>
>>> 2015-04-12 0:37 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>
>>>> Thanks, Achim.  I am using a custom Karaf distribution, but maintaining
>>>> deployment flexibility using features feels a little tougher than it feels
>>>> like it should be (I don't have any better ideas).
>>>>
>>> That's strange, cause features are there to make life easier not harder.
>>> Make sure you cut the features right, not to big but also not to small
>>> (like one bundle, one feature). Usually it helps to create those feature
>>> files yourself as the plugin can't estimate what your intension of this
>>> combination of bundles is.
>>>
>>>
>>>>   I also have issues with my Karaf integration tests in Bamboo.
>>>> Paxexam seems to not be able to initialize properly for who knows what
>>>> reason.  Another problem is that I seem to run into a lot of problems in
>>>> the tests and can't seem to find anything in the output or Karaf love that
>>>> indicate.the problem.  If I run it normally in Karaf, I usually get clued
>>>> into what the issue is.
>>>>
>>> Now that could be addressed. First of all, does it work for you on your
>>> machine? Is Bamboo capable of connecting to the internet.
>>> Is maven capable of connecting to the required repositories. Do you have
>>> all dependencies defined in your POM, so the configuration section of the
>>> test does find those (combined with the depends-maven-plugin)
>>>
>>>
>>>> One last thing is that since my development shop uses MacOSx, Docker
>>>> containers have to be run in a VM which feels silly and is slow.  I don't
>>>> have a choice in that manner.
>>>>
>>> Oh, I'm working with MacOSx too. I know it can be cumbersome but running
>>> 4 images in parallel can be done :-)
>>>
>>>
>>>
>>>> It would be nice if there was a way to manage feature xml files in a
>>>> way that felt more straight forward....  Maybe there is and I'm just not
>>>> aware of it.
>>>>
>>> You have the choices, use the karaf maven plugin for generation, or
>>> build those yourself. In the end it's up to how you want your application
>>> build.
>>> But maybe I miss something cause usually you have a certain set of
>>> bundles running in your application that need to run anyway. With this
>>> setup you can test your application.
>>>
>>>
>>>
>>>> On Apr 8, 2015 3:07 PM, "Achim Nierbeck" <bc...@googlemail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> just recently for a talk with showcase I was thinking about how to
>>>>> create a CI/CD build pipeline with Karaf. Maybe some of this does help
>>>>> you.[1]
>>>>> In the end I ended up with a setup where I have a pre-configured Karaf
>>>>> (custom build) which is startable as Docker Image or can be used as startup
>>>>> tar.gz of the Pax Exam integration tests.
>>>>> Usually camel routes are more about Integration therefore the most
>>>>> use-cases need to be handled by Integration tests. In those scenarios you
>>>>> just can't rely only on the camel-core bundles therefore you need more
>>>>> features just to have your unit tests/integration tests runnable. In those
>>>>> scenarios I usually suggest build your own distribution on top of Karaf and
>>>>> use it as your base-image in the pax-exam tests. If there is more external
>>>>> infrastructure needed I tend to use either full-integration test systems or
>>>>> now a docker based test-environment which can be started via a maven goal
>>>>> as pre-intergration phase systems.
>>>>>
>>>>> regards, Achim
>>>>>
>>>>> [1] - https://github.com/ANierbeck/JavaLang-Tooling
>>>>>
>>>>> 2015-04-08 17:24 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have another question regarding Karaf and deployments.  I was
>>>>>> hoping maybe some others could chime in on how they deal with the following
>>>>>> situation.
>>>>>>
>>>>>> I've been working on a fairly complex Karaf based application.  I'm
>>>>>> using features heavily to allow deploying the correct resources in
>>>>>> different environments (configuration and bundles).  I find it works very
>>>>>> well except for a couple situations:
>>>>>>
>>>>>> 1.  Unit testing.  It's hard to unit test things like camel routes
>>>>>> since I have ended up basically marking all bundle dependencies as provided
>>>>>> (in order to keep the created features files .  So if I try to unit test a
>>>>>> Camel route, transitive dependencies have to be directly added to the
>>>>>> project pom.
>>>>>>
>>>>>> 2.  I have all my configurations defined in a maven project for
>>>>>> assembling the final features xml file.  This of course doesn't make it
>>>>>> easy to use any of those configurations in camel integration tests since
>>>>>> configurations needed for config admin would have to be added to the
>>>>>> projects test resources.
>>>>>>
>>>>>> Obviously the two brief examples above focus mostly on Camel, but the
>>>>>> main problem is that I'm trying to figure out how I can no longer make
>>>>>> everything provided in my bundle project provided scope without having to
>>>>>> manually maintain the features files.
>>>>>>
>>>>>> That being said, I was looking at Apache Ace, but I'm not sure if
>>>>>> using Apache Ace would cause it to be more work to do Karaf integration
>>>>>> testing since Apache Ace doesn't use Karaf features.  I thought about maybe
>>>>>> using OBR, but we use Artifactory and so I'm not sure if going down the OBR
>>>>>> route might ultimately not be possible (I could be wrong but Artifactory
>>>>>> doesn't appear to have OBR support), also I read that OSGi has moved away
>>>>>> from OBR to different repository mechanism (forget offhand what it's
>>>>>> called).  I looked into Apache Cave, but I don't want to rock the boat
>>>>>> where I'm at yet since I'm the only one pushing Karaf and OSGi currently.
>>>>>> I don't want to try to push things out of my organizations comfort zone by
>>>>>> getting too radical in my project deployment.  I haven't gotten to read
>>>>>> into the Karaf 4.0 profiles yet.
>>>>>>
>>>>>> What it really boils down to is that I'm not sure which deployment
>>>>>> approach with Karaf would be the best to use out of all the options with
>>>>>> the goal of moving to a continuous deployment model.
>>>>>>
>>>>>> Hoping someone might be willing to comment on how they solved these
>>>>>> issues or maybe what direction I should look at going down that will allow
>>>>>> me to improve these aspects.  It took me a while to get things where they
>>>>>> are at, I want to be pretty confident in what path I go down next since if
>>>>>> it doesn't pan out, it will be a lot of potentially wasted time and effort.
>>>>>> :)
>>>>>>
>>>>>> Thanks in advance for any thoughts/suggestions.
>>>>>>
>>>>>> Ryan
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Apache Member
>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>> Committer & Project Lead
>>>>> blog <http://notizblog.nierbeck.de/>
>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>
>>>>> Software Architect / Project Manager / Scrum Master
>>>>>
>>>>>
>>>
>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>>> & Project Lead
>>> blog <http://notizblog.nierbeck.de/>
>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>
>>> Software Architect / Project Manager / Scrum Master
>>>
>>>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>

Re: Deploying applications on Karaf

[Achim Nierbeck <bc...@googlemail.com>]

Hi,

regarding OBR server, you still can use the Apache Karaf Cave modules to
turn one of your Karaf instances into an OBR server ;)

regards, Achim

2015-04-15 22:41 GMT+02:00 Ryan Moquin <fr...@gmail.com>:

> Thanks Achim.  I think that adding it to your pom with aggregate features
> set on the plugin will add it to the features xml.
>
> Ah, that's right.  That's what I observed and forgot that it matches what
> you guys said about feature uninstalling.
>
> I can't wait to try Karaf 4.
>
> I'll get details on it and ask the ops4j guys.
>
> I am thinking I should look into utilizing OBR with Karaf.  Not sure if
> Artifactory can function as an OBR like Nexus still.
>
> Thanks!
>
> Ryan
> Hi Ryan,
>
> some comments inline
>
> regards, Achim
>
>
> 2015-04-13 0:14 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>
>> Don't get me, features are a ton of help.  :)  I could maintain the
>> features myself, I just hate to have to keep two lists of dependencies.
>> The reason that the karaf maven plugin is a little tough sometimes is
>> because it's hard to make sure that you don't end up with bundles in a
>> generated feature that should come from a dependent feature without making
>> everything provided.  Making most of the dependencies provided makes it
>> hard to have transitive dependencies available in project dependencies
>> because they are marked provided in the other poms.  There is probably a
>> better way to handle it that I haven't figured out yet.  My project is
>> growing rapidly so I am trying to leverage whatever tools I can to keep my
>> features clean and not have to spend lots of time on them.
>>
>> Have you tried to add features as dependencies to your pom. AFAIK those
> should show up as dependencies in the generated features.xml. If not we
> just found a new use-case for the maven plugin and you could open an issue
> for it ;)
>
>
>> One thing I've been wrestling with (not sure if this has been improved in
>> Karaf 4)
>> is figuring out how to upgrade features and handle undeploying features..
>> I've played around with it but I guess I'm not sure I understand the proper
>> way to do it.  Such as if you had an application deployed in an environment
>> and wanted to upgrade a feature, do you have to install the new features
>> and uninstall the old one?  When I've tried to uninstall a feature
>> previously, it didn't seem like everything got removed.
>>
> Till Karaf 4, you explicitly need to uninstall transitive features because
> the features installer used to be quite dumb and therefore doesn't know of
> possible other dependencies on this feature.
> With Karaf 4 this will improve quite a bit.
>
>
>> I want want to be able to do incremental upgrades of my app but not sure
>> the best way to achieve that with features.  :)  I've done quite a lot of
>> research on it but haven't quite narrowed down a concrete way to do it (I
>> mean beyond manually upgrading individual bundles in the karaf console.)
>>
>> Upgrades is still an "open" field, with Karaf 4 I think it will be
> easier.
>
>
>> Our Bamboo instance has access to the internet.  I think it hangs right
>> at the beginning of Pax Exam starting up.  It's such a pain to deal with
>> our Bamboo EC2 instance that I haven't been able to find out why it's
>> hanging yet.
>>
> maybe post this as a question at the OPS4j list with some more details of
> the logfiles.
>
>
>
>
>> Ryan
>> On Apr 12, 2015 2:34 AM, "Achim Nierbeck" <bc...@googlemail.com>
>> wrote:
>>
>>> Hi Ryan,
>>>
>>> see comments inline.
>>>
>>> regards, Achim
>>>
>>>
>>> 2015-04-12 0:37 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>
>>>> Thanks, Achim.  I am using a custom Karaf distribution, but maintaining
>>>> deployment flexibility using features feels a little tougher than it feels
>>>> like it should be (I don't have any better ideas).
>>>>
>>> That's strange, cause features are there to make life easier not harder.
>>> Make sure you cut the features right, not to big but also not to small
>>> (like one bundle, one feature). Usually it helps to create those feature
>>> files yourself as the plugin can't estimate what your intension of this
>>> combination of bundles is.
>>>
>>>
>>>>   I also have issues with my Karaf integration tests in Bamboo.
>>>> Paxexam seems to not be able to initialize properly for who knows what
>>>> reason.  Another problem is that I seem to run into a lot of problems in
>>>> the tests and can't seem to find anything in the output or Karaf love that
>>>> indicate.the problem.  If I run it normally in Karaf, I usually get clued
>>>> into what the issue is.
>>>>
>>> Now that could be addressed. First of all, does it work for you on your
>>> machine? Is Bamboo capable of connecting to the internet.
>>> Is maven capable of connecting to the required repositories. Do you have
>>> all dependencies defined in your POM, so the configuration section of the
>>> test does find those (combined with the depends-maven-plugin)
>>>
>>>
>>>> One last thing is that since my development shop uses MacOSx, Docker
>>>> containers have to be run in a VM which feels silly and is slow.  I don't
>>>> have a choice in that manner.
>>>>
>>> Oh, I'm working with MacOSx too. I know it can be cumbersome but running
>>> 4 images in parallel can be done :-)
>>>
>>>
>>>
>>>> It would be nice if there was a way to manage feature xml files in a
>>>> way that felt more straight forward....  Maybe there is and I'm just not
>>>> aware of it.
>>>>
>>> You have the choices, use the karaf maven plugin for generation, or
>>> build those yourself. In the end it's up to how you want your application
>>> build.
>>> But maybe I miss something cause usually you have a certain set of
>>> bundles running in your application that need to run anyway. With this
>>> setup you can test your application.
>>>
>>>
>>>
>>>> On Apr 8, 2015 3:07 PM, "Achim Nierbeck" <bc...@googlemail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> just recently for a talk with showcase I was thinking about how to
>>>>> create a CI/CD build pipeline with Karaf. Maybe some of this does help
>>>>> you.[1]
>>>>> In the end I ended up with a setup where I have a pre-configured Karaf
>>>>> (custom build) which is startable as Docker Image or can be used as startup
>>>>> tar.gz of the Pax Exam integration tests.
>>>>> Usually camel routes are more about Integration therefore the most
>>>>> use-cases need to be handled by Integration tests. In those scenarios you
>>>>> just can't rely only on the camel-core bundles therefore you need more
>>>>> features just to have your unit tests/integration tests runnable. In those
>>>>> scenarios I usually suggest build your own distribution on top of Karaf and
>>>>> use it as your base-image in the pax-exam tests. If there is more external
>>>>> infrastructure needed I tend to use either full-integration test systems or
>>>>> now a docker based test-environment which can be started via a maven goal
>>>>> as pre-intergration phase systems.
>>>>>
>>>>> regards, Achim
>>>>>
>>>>> [1] - https://github.com/ANierbeck/JavaLang-Tooling
>>>>>
>>>>> 2015-04-08 17:24 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have another question regarding Karaf and deployments.  I was
>>>>>> hoping maybe some others could chime in on how they deal with the following
>>>>>> situation.
>>>>>>
>>>>>> I've been working on a fairly complex Karaf based application.  I'm
>>>>>> using features heavily to allow deploying the correct resources in
>>>>>> different environments (configuration and bundles).  I find it works very
>>>>>> well except for a couple situations:
>>>>>>
>>>>>> 1.  Unit testing.  It's hard to unit test things like camel routes
>>>>>> since I have ended up basically marking all bundle dependencies as provided
>>>>>> (in order to keep the created features files .  So if I try to unit test a
>>>>>> Camel route, transitive dependencies have to be directly added to the
>>>>>> project pom.
>>>>>>
>>>>>> 2.  I have all my configurations defined in a maven project for
>>>>>> assembling the final features xml file.  This of course doesn't make it
>>>>>> easy to use any of those configurations in camel integration tests since
>>>>>> configurations needed for config admin would have to be added to the
>>>>>> projects test resources.
>>>>>>
>>>>>> Obviously the two brief examples above focus mostly on Camel, but the
>>>>>> main problem is that I'm trying to figure out how I can no longer make
>>>>>> everything provided in my bundle project provided scope without having to
>>>>>> manually maintain the features files.
>>>>>>
>>>>>> That being said, I was looking at Apache Ace, but I'm not sure if
>>>>>> using Apache Ace would cause it to be more work to do Karaf integration
>>>>>> testing since Apache Ace doesn't use Karaf features.  I thought about maybe
>>>>>> using OBR, but we use Artifactory and so I'm not sure if going down the OBR
>>>>>> route might ultimately not be possible (I could be wrong but Artifactory
>>>>>> doesn't appear to have OBR support), also I read that OSGi has moved away
>>>>>> from OBR to different repository mechanism (forget offhand what it's
>>>>>> called).  I looked into Apache Cave, but I don't want to rock the boat
>>>>>> where I'm at yet since I'm the only one pushing Karaf and OSGi currently.
>>>>>> I don't want to try to push things out of my organizations comfort zone by
>>>>>> getting too radical in my project deployment.  I haven't gotten to read
>>>>>> into the Karaf 4.0 profiles yet.
>>>>>>
>>>>>> What it really boils down to is that I'm not sure which deployment
>>>>>> approach with Karaf would be the best to use out of all the options with
>>>>>> the goal of moving to a continuous deployment model.
>>>>>>
>>>>>> Hoping someone might be willing to comment on how they solved these
>>>>>> issues or maybe what direction I should look at going down that will allow
>>>>>> me to improve these aspects.  It took me a while to get things where they
>>>>>> are at, I want to be pretty confident in what path I go down next since if
>>>>>> it doesn't pan out, it will be a lot of potentially wasted time and effort.
>>>>>> :)
>>>>>>
>>>>>> Thanks in advance for any thoughts/suggestions.
>>>>>>
>>>>>> Ryan
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Apache Member
>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>> Committer & Project Lead
>>>>> blog <http://notizblog.nierbeck.de/>
>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>
>>>>> Software Architect / Project Manager / Scrum Master
>>>>>
>>>>>
>>>
>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>>> & Project Lead
>>> blog <http://notizblog.nierbeck.de/>
>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>
>>> Software Architect / Project Manager / Scrum Master
>>>
>>>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>


-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: Deploying applications on Karaf

[Ryan Moquin <fr...@gmail.com>]

Thanks Achim.  I think that adding it to your pom with aggregate features
set on the plugin will add it to the features xml.

Ah, that's right.  That's what I observed and forgot that it matches what
you guys said about feature uninstalling.

I can't wait to try Karaf 4.

I'll get details on it and ask the ops4j guys.

I am thinking I should look into utilizing OBR with Karaf.  Not sure if
Artifactory can function as an OBR like Nexus still.

Thanks!

Ryan
Hi Ryan,

some comments inline

regards, Achim


2015-04-13 0:14 GMT+02:00 Ryan Moquin <fr...@gmail.com>:

> Don't get me, features are a ton of help.  :)  I could maintain the
> features myself, I just hate to have to keep two lists of dependencies.
> The reason that the karaf maven plugin is a little tough sometimes is
> because it's hard to make sure that you don't end up with bundles in a
> generated feature that should come from a dependent feature without making
> everything provided.  Making most of the dependencies provided makes it
> hard to have transitive dependencies available in project dependencies
> because they are marked provided in the other poms.  There is probably a
> better way to handle it that I haven't figured out yet.  My project is
> growing rapidly so I am trying to leverage whatever tools I can to keep my
> features clean and not have to spend lots of time on them.
>
> Have you tried to add features as dependencies to your pom. AFAIK those
should show up as dependencies in the generated features.xml. If not we
just found a new use-case for the maven plugin and you could open an issue
for it ;)


> One thing I've been wrestling with (not sure if this has been improved in
> Karaf 4)
> is figuring out how to upgrade features and handle undeploying features..
> I've played around with it but I guess I'm not sure I understand the proper
> way to do it.  Such as if you had an application deployed in an environment
> and wanted to upgrade a feature, do you have to install the new features
> and uninstall the old one?  When I've tried to uninstall a feature
> previously, it didn't seem like everything got removed.
>
Till Karaf 4, you explicitly need to uninstall transitive features because
the features installer used to be quite dumb and therefore doesn't know of
possible other dependencies on this feature.
With Karaf 4 this will improve quite a bit.


> I want want to be able to do incremental upgrades of my app but not sure
> the best way to achieve that with features.  :)  I've done quite a lot of
> research on it but haven't quite narrowed down a concrete way to do it (I
> mean beyond manually upgrading individual bundles in the karaf console.)
>
> Upgrades is still an "open" field, with Karaf 4 I think it will be easier.


> Our Bamboo instance has access to the internet.  I think it hangs right at
> the beginning of Pax Exam starting up.  It's such a pain to deal with our
> Bamboo EC2 instance that I haven't been able to find out why it's hanging
> yet.
>
maybe post this as a question at the OPS4j list with some more details of
the logfiles.




> Ryan
> On Apr 12, 2015 2:34 AM, "Achim Nierbeck" <bc...@googlemail.com> wrote:
>
>> Hi Ryan,
>>
>> see comments inline.
>>
>> regards, Achim
>>
>>
>> 2015-04-12 0:37 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>
>>> Thanks, Achim.  I am using a custom Karaf distribution, but maintaining
>>> deployment flexibility using features feels a little tougher than it feels
>>> like it should be (I don't have any better ideas).
>>>
>> That's strange, cause features are there to make life easier not harder.
>> Make sure you cut the features right, not to big but also not to small
>> (like one bundle, one feature). Usually it helps to create those feature
>> files yourself as the plugin can't estimate what your intension of this
>> combination of bundles is.
>>
>>
>>>   I also have issues with my Karaf integration tests in Bamboo.  Paxexam
>>> seems to not be able to initialize properly for who knows what reason.
>>> Another problem is that I seem to run into a lot of problems in the tests
>>> and can't seem to find anything in the output or Karaf love that
>>> indicate.the problem.  If I run it normally in Karaf, I usually get clued
>>> into what the issue is.
>>>
>> Now that could be addressed. First of all, does it work for you on your
>> machine? Is Bamboo capable of connecting to the internet.
>> Is maven capable of connecting to the required repositories. Do you have
>> all dependencies defined in your POM, so the configuration section of the
>> test does find those (combined with the depends-maven-plugin)
>>
>>
>>> One last thing is that since my development shop uses MacOSx, Docker
>>> containers have to be run in a VM which feels silly and is slow.  I don't
>>> have a choice in that manner.
>>>
>> Oh, I'm working with MacOSx too. I know it can be cumbersome but running
>> 4 images in parallel can be done :-)
>>
>>
>>
>>> It would be nice if there was a way to manage feature xml files in a way
>>> that felt more straight forward....  Maybe there is and I'm just not aware
>>> of it.
>>>
>> You have the choices, use the karaf maven plugin for generation, or build
>> those yourself. In the end it's up to how you want your application build.
>> But maybe I miss something cause usually you have a certain set of
>> bundles running in your application that need to run anyway. With this
>> setup you can test your application.
>>
>>
>>
>>> On Apr 8, 2015 3:07 PM, "Achim Nierbeck" <bc...@googlemail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> just recently for a talk with showcase I was thinking about how to
>>>> create a CI/CD build pipeline with Karaf. Maybe some of this does help
>>>> you.[1]
>>>> In the end I ended up with a setup where I have a pre-configured Karaf
>>>> (custom build) which is startable as Docker Image or can be used as startup
>>>> tar.gz of the Pax Exam integration tests.
>>>> Usually camel routes are more about Integration therefore the most
>>>> use-cases need to be handled by Integration tests. In those scenarios you
>>>> just can't rely only on the camel-core bundles therefore you need more
>>>> features just to have your unit tests/integration tests runnable. In those
>>>> scenarios I usually suggest build your own distribution on top of Karaf and
>>>> use it as your base-image in the pax-exam tests. If there is more external
>>>> infrastructure needed I tend to use either full-integration test systems or
>>>> now a docker based test-environment which can be started via a maven goal
>>>> as pre-intergration phase systems.
>>>>
>>>> regards, Achim
>>>>
>>>> [1] - https://github.com/ANierbeck/JavaLang-Tooling
>>>>
>>>> 2015-04-08 17:24 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have another question regarding Karaf and deployments.  I was hoping
>>>>> maybe some others could chime in on how they deal with the following
>>>>> situation.
>>>>>
>>>>> I've been working on a fairly complex Karaf based application.  I'm
>>>>> using features heavily to allow deploying the correct resources in
>>>>> different environments (configuration and bundles).  I find it works very
>>>>> well except for a couple situations:
>>>>>
>>>>> 1.  Unit testing.  It's hard to unit test things like camel routes
>>>>> since I have ended up basically marking all bundle dependencies as provided
>>>>> (in order to keep the created features files .  So if I try to unit test a
>>>>> Camel route, transitive dependencies have to be directly added to the
>>>>> project pom.
>>>>>
>>>>> 2.  I have all my configurations defined in a maven project for
>>>>> assembling the final features xml file.  This of course doesn't make it
>>>>> easy to use any of those configurations in camel integration tests since
>>>>> configurations needed for config admin would have to be added to the
>>>>> projects test resources.
>>>>>
>>>>> Obviously the two brief examples above focus mostly on Camel, but the
>>>>> main problem is that I'm trying to figure out how I can no longer make
>>>>> everything provided in my bundle project provided scope without having to
>>>>> manually maintain the features files.
>>>>>
>>>>> That being said, I was looking at Apache Ace, but I'm not sure if
>>>>> using Apache Ace would cause it to be more work to do Karaf integration
>>>>> testing since Apache Ace doesn't use Karaf features.  I thought about maybe
>>>>> using OBR, but we use Artifactory and so I'm not sure if going down the OBR
>>>>> route might ultimately not be possible (I could be wrong but Artifactory
>>>>> doesn't appear to have OBR support), also I read that OSGi has moved away
>>>>> from OBR to different repository mechanism (forget offhand what it's
>>>>> called).  I looked into Apache Cave, but I don't want to rock the boat
>>>>> where I'm at yet since I'm the only one pushing Karaf and OSGi currently.
>>>>> I don't want to try to push things out of my organizations comfort zone by
>>>>> getting too radical in my project deployment.  I haven't gotten to read
>>>>> into the Karaf 4.0 profiles yet.
>>>>>
>>>>> What it really boils down to is that I'm not sure which deployment
>>>>> approach with Karaf would be the best to use out of all the options with
>>>>> the goal of moving to a continuous deployment model.
>>>>>
>>>>> Hoping someone might be willing to comment on how they solved these
>>>>> issues or maybe what direction I should look at going down that will allow
>>>>> me to improve these aspects.  It took me a while to get things where they
>>>>> are at, I want to be pretty confident in what path I go down next since if
>>>>> it doesn't pan out, it will be a lot of potentially wasted time and effort.
>>>>> :)
>>>>>
>>>>> Thanks in advance for any thoughts/suggestions.
>>>>>
>>>>> Ryan
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Apache Member
>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>> Committer & Project Lead
>>>> blog <http://notizblog.nierbeck.de/>
>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>
>>>> Software Architect / Project Manager / Scrum Master
>>>>
>>>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>


-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: Deploying applications on Karaf

[Achim Nierbeck <bc...@googlemail.com>]

Hi,

I pretty much agree with all of your points. But there are some ways of
working around the "documentation/build" part of Docker images. It is
actually possible to have a pom-only documentation for a Docker Image. With
the right Plugins you have the same as the Docker file. Though I regard
such solutions only feasible for testing to make sure Continous Integration
with more than one Container works. Otherwise I'd rather stick to Pax Exam
with Karaf as Integration test.

regards, Achim


2015-04-13 16:54 GMT+02:00 Ed Welch <ed...@edjusted.com>:

> Hi David,
>
> There are kind of 2 threads in parallel covering a little bit of the same
> info, and I just talked a little about the big question/issue we have in
> the other thread:
> http://karaf.922171.n3.nabble.com/Karaf-and-Docker-td4039514.html
>
> I'll kind of give the brief overview of that here.  We have some difficult
> to answer questions regarding ownership of the linux distro that exists
> within the docker container.  Our linux team owns the VM that runs docker,
> but then do they have to learn docker in order to handle software updates
> to the docker container?  Or does this fall on the dev group to now
> maintain?
>
> So with that question in mind, I found it easier to work within a linux VM
> owned by our linux ops team, and Ansible was the software I chose to
> provide automation around deployments.
>
> I would also point out though, the physical overhead of deployments is
> smaller, and depending on your network, faster.  Docker images will be
> large, telling karaf to install a feature is going to be smaller.  Also, we
> don't update karaf/java very often, so the app server is deployed pretty
> infrequently.  (depending on your network, size may be a moot point)
>
> I also like the approach I have taken because everything is explicitly
> defined and in source control.  The karaf config files are in source
> control, the application and its current version is as well.  I could
> technically use ansible to deploy my setup into a docker container and then
> ship that container.
>
> I'm not opposed to docker, just a little more skeptical than my peers.  My
> fear is they will build images on their local machine with poor
> documentation, nothing tracked in source control, bash it together and make
> it work then ship that off to production, where docker really facilitates
> making that easy.  Which I think is seen as a positive in many peoples
> minds, I am a little more skeptical.
>
> However, at this point I don't have a lot of docker experience, and I am
> trying to find some time to explore it.
>
> I appreciate the question, it's important to me that I'm being open
> minded, especially because I haven't used docker extensively.
>
> TLDR; If you can figure out who "owns" docker containers and maintains
> them in your organization, and you can also enforce some good practices
> around documentation and source control of container configurations so that
> future maintenance and troubleshooting is made easier, and you don't mind
> paying the 300+MB per deploy penalty, docker may be great for you! :)
>
> Ed




-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: Deploying applications on Karaf

[ch...@kiffer.ltd.uk]

No, Ed is saying that in most cases he does indeed update his production
karaf instances; however some components (e.g. Apache Karaf) don't take
well to this and then he has to re-deploy Karaf. So re-deployment is the
exception not the rule.

I think the question is whether it really is easier and cheaper to replace
100% of your production instance rather than 1%, and if so whether this is
enough to make this option "better"? Is "I upgraded Windows from 8.0 to
8.1 and now my built-in microphone no longer works" actually a better
place to be than "I upgraded the Creative drivers and now my built-in
microphone no longer works"?

> I have no hands on experience with most of these technologies, and am
> really looking for information not trolling….  why wouldn't this be
> simpler using docker?  Do you update your production karaf instances
> rather than redeploy them?  My impression is that you say you basically
> redeploy karaf when a change is needed, using ansible.  Would you get more
> or less the same effect rebuilding the appropriate docker container and
> (re)-deploying it?
>
> thanks for any insights….
>
> david jencks
>
> On Apr 13, 2015, at 10:15 AM, "Ed Welch" <ed...@edjusted.com> wrote:
>
>> This is a topic I've spent some time on myself and I like this
>> discussion.
>>
>> Ryan, you have asked a lot of questions I have had, and raised some
>> concerns I have had as well.
>>
>> For what it's worth, here is my current setup:
>>
>> I hand maintain a features.xml file for each of my applications (a
>> cohesive grouping of bundles and dependencies that make up an
>> application).  I usually only deploy one, maybe two "applications" into
>> one instance of karaf (and run many instances of karaf on one server).
>>
>> I have not spent much time with the maven plugin for generating
>> features, so I can't comment on it too much.  What I usually do is put
>> the features.xml in its own maven submodule along side the other modules
>> in my project, which makes it easy to rebuild it and do a repo-refresh
>> for development.
>>
>> This does require me to maintain dependencies twice which I don't love,
>> but it also keeps me very close with my projects dependencies and
>> transitive dependencies which I think has helped me build better
>> applications, and certainly made me more mindful of "bad" libraries
>> which include layers upon layers of transitive dependencies.  (which
>> makes me think of the package-the-world strategy a lot of people use
>> even within maven, which you were discussing in regards to docker in
>> another thread)
>>
>> As far as deployment.  I've always kind of considered the features
>> support in karaf a little soft.  Mainly the lack of in place upgrade or
>> lack of dependent feature uninstall, the latter being addressed in karaf
>> 4.
>>
>> So what I came up with was a merger of another technology that i've been
>> toying with, Ansible.  On my dev box I try to take full advantage of the
>> OSGi modularity and hot swapping capabilities, I install the app from my
>> features file through the console and then use bundle:watch religiously
>> while developing.  I run into a few hiccups when using blueprint
>> services and bundle:watch as bundles will hang onto stale references of
>> services and sometimes I have to swap over to the command console and
>> punch in an a restart, refresh, or update by hand.  But really this
>> works well, and I find very fast.  (I've also started learning and
>> toying with declarative services, which I think would address some of my
>> reference issues)
>>
>> When i move off my machine, I let Ansible take over.  I setup ansible to
>> deploy karaf, i often have many karaf deployments on one machine, I
>> favor setting up many standalone instances rather than using the built
>> in karaf instances functionality, as most of the time the karaf
>> instances get their own linux user to provide a nice level of isolation.
>>
>> I always deploy karaf with jolokia, then, using a python module I wrote
>> for ansible, which really just executes simple http calls to jolokia to
>> execute features install commands.  I have an ansible .yml file which
>> lists out the feature repo url's and the features I want installed, and
>> ansible then installs them:
>>
>> ##### SOA USER #################################################
>>
>> soa_version:            '0.1.11'
>> soa_camel_version:      '2.15.1'
>> soa_activemq_version:   '5.11.1'
>> soa_infinispan_version: '7.1.1.Final'
>>
>> soa_repos:
>>  - { url: 'mvn:org.apache.camel.karaf/apache-camel/{{ soa_camel_version
>> }}/xml/features' }
>>  - { url: 'mvn:org.apache.activemq/activemq-karaf/{{
>> soa_activemq_version }}/xml/features' }
>>  - { url: 'mvn:org.infinispan/infinispan-core/{{ soa_infinispan_version
>> }}/xml/features' }
>>  - { url: 'mvn:com.earthlink.business/soa-feature/{{ soa_version
>> }}/xml/features' }
>>
>> soa_features:
>>  - { name: 'webconsole', version: '' }
>>  - { name: 'elnk-soa-feature-dev', version: '{{ soa_version }}' }
>>
>> We are on Karaf 3 in our prod environments, which doesn't do dependent
>> feature uninstall, which makes upgrading something like camel a little
>> tricky, so i've been handling upgrades by bringing down karaf, deleting
>> the data/cache dir, bring it back up as if it were a clean install, and
>> then installing the features as mentioned above, ansible does all this
>> for me.
>>
>> I know this isn't very modular, or on the fly, or OSGi.  But it's very
>> reliable, guarantees me the app server is the way I expect it, and
>> because they run in clusters, the downtime doesn't hurt anybody.   The
>> other thing I don't like is that I have configs in pom files for the
>> app, features file for the feature, and this ansible file for the
>> server.  Most of my peers are dumb and this hurts their brain.  Maybe
>> i'm just being bullish because I built it... but they just keep telling
>> me that they want to use docker, and that if they used docker they
>> wouldn't have to do any of this... sigh...
>>
>> With the dependent feature uninstall in karaf 4, i may revist this.  but
>> to be honest, I really love that I can delete that cache dir and have a
>> clean slate.  And for my production environments, this isn't really
>> causing us any problems.  I still get plenty of use of live reload and
>> the OSGi benefits both from a nice modular application design, and in my
>> development stages.
>>
>>
>> Would love any feedback, and hope maybe my usage may be interesting or
>> inspiring to anyone.
>>
>> Ed
>
>

Re: Deploying applications on Karaf

[Ed Welch <ed...@edjusted.com>]

Hi David,

There are kind of 2 threads in parallel covering a little bit of the same info, and I just talked a little about the big question/issue we have in the other thread: http://karaf.922171.n3.nabble.com/Karaf-and-Docker-td4039514.html  

I'll kind of give the brief overview of that here.  We have some difficult to answer questions regarding ownership of the linux distro that exists within the docker container.  Our linux team owns the VM that runs docker, but then do they have to learn docker in order to handle software updates to the docker container?  Or does this fall on the dev group to now maintain?

So with that question in mind, I found it easier to work within a linux VM owned by our linux ops team, and Ansible was the software I chose to provide automation around deployments.

I would also point out though, the physical overhead of deployments is smaller, and depending on your network, faster.  Docker images will be large, telling karaf to install a feature is going to be smaller.  Also, we don't update karaf/java very often, so the app server is deployed pretty infrequently.  (depending on your network, size may be a moot point)

I also like the approach I have taken because everything is explicitly defined and in source control.  The karaf config files are in source control, the application and its current version is as well.  I could technically use ansible to deploy my setup into a docker container and then ship that container.  

I'm not opposed to docker, just a little more skeptical than my peers.  My fear is they will build images on their local machine with poor documentation, nothing tracked in source control, bash it together and make it work then ship that off to production, where docker really facilitates making that easy.  Which I think is seen as a positive in many peoples minds, I am a little more skeptical.

However, at this point I don't have a lot of docker experience, and I am trying to find some time to explore it.

I appreciate the question, it's important to me that I'm being open minded, especially because I haven't used docker extensively.

TLDR; If you can figure out who "owns" docker containers and maintains them in your organization, and you can also enforce some good practices around documentation and source control of container configurations so that future maintenance and troubleshooting is made easier, and you don't mind paying the 300+MB per deploy penalty, docker may be great for you! :)

Ed

Re: Deploying applications on Karaf

[David Jencks <da...@yahoo.com>]

I have no hands on experience with most of these technologies, and am really looking for information not trolling….  why wouldn't this be simpler using docker?  Do you update your production karaf instances rather than redeploy them?  My impression is that you say you basically redeploy karaf when a change is needed, using ansible.  Would you get more or less the same effect rebuilding the appropriate docker container and (re)-deploying it?

thanks for any insights….

david jencks

On Apr 13, 2015, at 10:15 AM, "Ed Welch" <ed...@edjusted.com> wrote:

> This is a topic I've spent some time on myself and I like this discussion.
> 
> Ryan, you have asked a lot of questions I have had, and raised some concerns I have had as well.
> 
> For what it's worth, here is my current setup:
> 
> I hand maintain a features.xml file for each of my applications (a cohesive grouping of bundles and dependencies that make up an application).  I usually only deploy one, maybe two "applications" into one instance of karaf (and run many instances of karaf on one server).
> 
> I have not spent much time with the maven plugin for generating features, so I can't comment on it too much.  What I usually do is put the features.xml in its own maven submodule along side the other modules in my project, which makes it easy to rebuild it and do a repo-refresh for development.
> 
> This does require me to maintain dependencies twice which I don't love, but it also keeps me very close with my projects dependencies and transitive dependencies which I think has helped me build better applications, and certainly made me more mindful of "bad" libraries which include layers upon layers of transitive dependencies.  (which makes me think of the package-the-world strategy a lot of people use even within maven, which you were discussing in regards to docker in another thread)
> 
> As far as deployment.  I've always kind of considered the features support in karaf a little soft.  Mainly the lack of in place upgrade or lack of dependent feature uninstall, the latter being addressed in karaf 4.
> 
> So what I came up with was a merger of another technology that i've been toying with, Ansible.  On my dev box I try to take full advantage of the OSGi modularity and hot swapping capabilities, I install the app from my features file through the console and then use bundle:watch religiously while developing.  I run into a few hiccups when using blueprint services and bundle:watch as bundles will hang onto stale references of services and sometimes I have to swap over to the command console and punch in an a restart, refresh, or update by hand.  But really this works well, and I find very fast.  (I've also started learning and toying with declarative services, which I think would address some of my reference issues)
> 
> When i move off my machine, I let Ansible take over.  I setup ansible to deploy karaf, i often have many karaf deployments on one machine, I favor setting up many standalone instances rather than using the built in karaf instances functionality, as most of the time the karaf instances get their own linux user to provide a nice level of isolation.
> 
> I always deploy karaf with jolokia, then, using a python module I wrote for ansible, which really just executes simple http calls to jolokia to execute features install commands.  I have an ansible .yml file which lists out the feature repo url's and the features I want installed, and ansible then installs them:
> 
> ##### SOA USER #################################################
> 
> soa_version:            '0.1.11'
> soa_camel_version:      '2.15.1'
> soa_activemq_version:   '5.11.1'
> soa_infinispan_version: '7.1.1.Final'
> 
> soa_repos:
>  - { url: 'mvn:org.apache.camel.karaf/apache-camel/{{ soa_camel_version }}/xml/features' }
>  - { url: 'mvn:org.apache.activemq/activemq-karaf/{{ soa_activemq_version }}/xml/features' }
>  - { url: 'mvn:org.infinispan/infinispan-core/{{ soa_infinispan_version }}/xml/features' }
>  - { url: 'mvn:com.earthlink.business/soa-feature/{{ soa_version }}/xml/features' }
> 
> soa_features:
>  - { name: 'webconsole', version: '' }
>  - { name: 'elnk-soa-feature-dev', version: '{{ soa_version }}' }
> 
> We are on Karaf 3 in our prod environments, which doesn't do dependent feature uninstall, which makes upgrading something like camel a little tricky, so i've been handling upgrades by bringing down karaf, deleting the data/cache dir, bring it back up as if it were a clean install, and then installing the features as mentioned above, ansible does all this for me.
> 
> I know this isn't very modular, or on the fly, or OSGi.  But it's very reliable, guarantees me the app server is the way I expect it, and because they run in clusters, the downtime doesn't hurt anybody.   The other thing I don't like is that I have configs in pom files for the app, features file for the feature, and this ansible file for the server.  Most of my peers are dumb and this hurts their brain.  Maybe i'm just being bullish because I built it... but they just keep telling me that they want to use docker, and that if they used docker they wouldn't have to do any of this... sigh...
> 
> With the dependent feature uninstall in karaf 4, i may revist this.  but to be honest, I really love that I can delete that cache dir and have a clean slate.  And for my production environments, this isn't really causing us any problems.  I still get plenty of use of live reload and the OSGi benefits both from a nice modular application design, and in my development stages.
> 
> 
> Would love any feedback, and hope maybe my usage may be interesting or inspiring to anyone.
> 
> Ed

Re: Deploying applications on Karaf

[Ed Welch <ed...@edjusted.com>]

This is a topic I've spent some time on myself and I like this discussion.

Ryan, you have asked a lot of questions I have had, and raised some concerns I have had as well.

For what it's worth, here is my current setup:

I hand maintain a features.xml file for each of my applications (a cohesive grouping of bundles and dependencies that make up an application).  I usually only deploy one, maybe two "applications" into one instance of karaf (and run many instances of karaf on one server).

I have not spent much time with the maven plugin for generating features, so I can't comment on it too much.  What I usually do is put the features.xml in its own maven submodule along side the other modules in my project, which makes it easy to rebuild it and do a repo-refresh for development.

This does require me to maintain dependencies twice which I don't love, but it also keeps me very close with my projects dependencies and transitive dependencies which I think has helped me build better applications, and certainly made me more mindful of "bad" libraries which include layers upon layers of transitive dependencies.  (which makes me think of the package-the-world strategy a lot of people use even within maven, which you were discussing in regards to docker in another thread)

As far as deployment.  I've always kind of considered the features support in karaf a little soft.  Mainly the lack of in place upgrade or lack of dependent feature uninstall, the latter being addressed in karaf 4.

So what I came up with was a merger of another technology that i've been toying with, Ansible.  On my dev box I try to take full advantage of the OSGi modularity and hot swapping capabilities, I install the app from my features file through the console and then use bundle:watch religiously while developing.  I run into a few hiccups when using blueprint services and bundle:watch as bundles will hang onto stale references of services and sometimes I have to swap over to the command console and punch in an a restart, refresh, or update by hand.  But really this works well, and I find very fast.  (I've also started learning and toying with declarative services, which I think would address some of my reference issues)

When i move off my machine, I let Ansible take over.  I setup ansible to deploy karaf, i often have many karaf deployments on one machine, I favor setting up many standalone instances rather than using the built in karaf instances functionality, as most of the time the karaf instances get their own linux user to provide a nice level of isolation.

I always deploy karaf with jolokia, then, using a python module I wrote for ansible, which really just executes simple http calls to jolokia to execute features install commands.  I have an ansible .yml file which lists out the feature repo url's and the features I want installed, and ansible then installs them:

##### SOA USER #################################################

soa_version:            '0.1.11'
soa_camel_version:      '2.15.1'
soa_activemq_version:   '5.11.1'
soa_infinispan_version: '7.1.1.Final'

soa_repos:
  - { url: 'mvn:org.apache.camel.karaf/apache-camel/{{ soa_camel_version }}/xml/features' }
  - { url: 'mvn:org.apache.activemq/activemq-karaf/{{ soa_activemq_version }}/xml/features' }
  - { url: 'mvn:org.infinispan/infinispan-core/{{ soa_infinispan_version }}/xml/features' }
  - { url: 'mvn:com.earthlink.business/soa-feature/{{ soa_version }}/xml/features' }

soa_features:
  - { name: 'webconsole', version: '' }
  - { name: 'elnk-soa-feature-dev', version: '{{ soa_version }}' }

We are on Karaf 3 in our prod environments, which doesn't do dependent feature uninstall, which makes upgrading something like camel a little tricky, so i've been handling upgrades by bringing down karaf, deleting the data/cache dir, bring it back up as if it were a clean install, and then installing the features as mentioned above, ansible does all this for me.

I know this isn't very modular, or on the fly, or OSGi.  But it's very reliable, guarantees me the app server is the way I expect it, and because they run in clusters, the downtime doesn't hurt anybody.   The other thing I don't like is that I have configs in pom files for the app, features file for the feature, and this ansible file for the server.  Most of my peers are dumb and this hurts their brain.  Maybe i'm just being bullish because I built it... but they just keep telling me that they want to use docker, and that if they used docker they wouldn't have to do any of this... sigh...

With the dependent feature uninstall in karaf 4, i may revist this.  but to be honest, I really love that I can delete that cache dir and have a clean slate.  And for my production environments, this isn't really causing us any problems.  I still get plenty of use of live reload and the OSGi benefits both from a nice modular application design, and in my development stages.


Would love any feedback, and hope maybe my usage may be interesting or inspiring to anyone.

Ed

Re: Deploying applications on Karaf

[Achim Nierbeck <bc...@googlemail.com>]

Hi Ryan,

some comments inline

regards, Achim


2015-04-13 0:14 GMT+02:00 Ryan Moquin <fr...@gmail.com>:

> Don't get me, features are a ton of help.  :)  I could maintain the
> features myself, I just hate to have to keep two lists of dependencies.
> The reason that the karaf maven plugin is a little tough sometimes is
> because it's hard to make sure that you don't end up with bundles in a
> generated feature that should come from a dependent feature without making
> everything provided.  Making most of the dependencies provided makes it
> hard to have transitive dependencies available in project dependencies
> because they are marked provided in the other poms.  There is probably a
> better way to handle it that I haven't figured out yet.  My project is
> growing rapidly so I am trying to leverage whatever tools I can to keep my
> features clean and not have to spend lots of time on them.
>
> Have you tried to add features as dependencies to your pom. AFAIK those
should show up as dependencies in the generated features.xml. If not we
just found a new use-case for the maven plugin and you could open an issue
for it ;)


> One thing I've been wrestling with (not sure if this has been improved in
> Karaf 4)
> is figuring out how to upgrade features and handle undeploying features..
> I've played around with it but I guess I'm not sure I understand the proper
> way to do it.  Such as if you had an application deployed in an environment
> and wanted to upgrade a feature, do you have to install the new features
> and uninstall the old one?  When I've tried to uninstall a feature
> previously, it didn't seem like everything got removed.
>
Till Karaf 4, you explicitly need to uninstall transitive features because
the features installer used to be quite dumb and therefore doesn't know of
possible other dependencies on this feature.
With Karaf 4 this will improve quite a bit.


> I want want to be able to do incremental upgrades of my app but not sure
> the best way to achieve that with features.  :)  I've done quite a lot of
> research on it but haven't quite narrowed down a concrete way to do it (I
> mean beyond manually upgrading individual bundles in the karaf console.)
>
> Upgrades is still an "open" field, with Karaf 4 I think it will be easier.


> Our Bamboo instance has access to the internet.  I think it hangs right at
> the beginning of Pax Exam starting up.  It's such a pain to deal with our
> Bamboo EC2 instance that I haven't been able to find out why it's hanging
> yet.
>
maybe post this as a question at the OPS4j list with some more details of
the logfiles.




> Ryan
> On Apr 12, 2015 2:34 AM, "Achim Nierbeck" <bc...@googlemail.com> wrote:
>
>> Hi Ryan,
>>
>> see comments inline.
>>
>> regards, Achim
>>
>>
>> 2015-04-12 0:37 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>
>>> Thanks, Achim.  I am using a custom Karaf distribution, but maintaining
>>> deployment flexibility using features feels a little tougher than it feels
>>> like it should be (I don't have any better ideas).
>>>
>> That's strange, cause features are there to make life easier not harder.
>> Make sure you cut the features right, not to big but also not to small
>> (like one bundle, one feature). Usually it helps to create those feature
>> files yourself as the plugin can't estimate what your intension of this
>> combination of bundles is.
>>
>>
>>>   I also have issues with my Karaf integration tests in Bamboo.  Paxexam
>>> seems to not be able to initialize properly for who knows what reason.
>>> Another problem is that I seem to run into a lot of problems in the tests
>>> and can't seem to find anything in the output or Karaf love that
>>> indicate.the problem.  If I run it normally in Karaf, I usually get clued
>>> into what the issue is.
>>>
>> Now that could be addressed. First of all, does it work for you on your
>> machine? Is Bamboo capable of connecting to the internet.
>> Is maven capable of connecting to the required repositories. Do you have
>> all dependencies defined in your POM, so the configuration section of the
>> test does find those (combined with the depends-maven-plugin)
>>
>>
>>> One last thing is that since my development shop uses MacOSx, Docker
>>> containers have to be run in a VM which feels silly and is slow.  I don't
>>> have a choice in that manner.
>>>
>> Oh, I'm working with MacOSx too. I know it can be cumbersome but running
>> 4 images in parallel can be done :-)
>>
>>
>>
>>> It would be nice if there was a way to manage feature xml files in a way
>>> that felt more straight forward....  Maybe there is and I'm just not aware
>>> of it.
>>>
>> You have the choices, use the karaf maven plugin for generation, or build
>> those yourself. In the end it's up to how you want your application build.
>> But maybe I miss something cause usually you have a certain set of
>> bundles running in your application that need to run anyway. With this
>> setup you can test your application.
>>
>>
>>
>>> On Apr 8, 2015 3:07 PM, "Achim Nierbeck" <bc...@googlemail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> just recently for a talk with showcase I was thinking about how to
>>>> create a CI/CD build pipeline with Karaf. Maybe some of this does help
>>>> you.[1]
>>>> In the end I ended up with a setup where I have a pre-configured Karaf
>>>> (custom build) which is startable as Docker Image or can be used as startup
>>>> tar.gz of the Pax Exam integration tests.
>>>> Usually camel routes are more about Integration therefore the most
>>>> use-cases need to be handled by Integration tests. In those scenarios you
>>>> just can't rely only on the camel-core bundles therefore you need more
>>>> features just to have your unit tests/integration tests runnable. In those
>>>> scenarios I usually suggest build your own distribution on top of Karaf and
>>>> use it as your base-image in the pax-exam tests. If there is more external
>>>> infrastructure needed I tend to use either full-integration test systems or
>>>> now a docker based test-environment which can be started via a maven goal
>>>> as pre-intergration phase systems.
>>>>
>>>> regards, Achim
>>>>
>>>> [1] - https://github.com/ANierbeck/JavaLang-Tooling
>>>>
>>>> 2015-04-08 17:24 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have another question regarding Karaf and deployments.  I was hoping
>>>>> maybe some others could chime in on how they deal with the following
>>>>> situation.
>>>>>
>>>>> I've been working on a fairly complex Karaf based application.  I'm
>>>>> using features heavily to allow deploying the correct resources in
>>>>> different environments (configuration and bundles).  I find it works very
>>>>> well except for a couple situations:
>>>>>
>>>>> 1.  Unit testing.  It's hard to unit test things like camel routes
>>>>> since I have ended up basically marking all bundle dependencies as provided
>>>>> (in order to keep the created features files .  So if I try to unit test a
>>>>> Camel route, transitive dependencies have to be directly added to the
>>>>> project pom.
>>>>>
>>>>> 2.  I have all my configurations defined in a maven project for
>>>>> assembling the final features xml file.  This of course doesn't make it
>>>>> easy to use any of those configurations in camel integration tests since
>>>>> configurations needed for config admin would have to be added to the
>>>>> projects test resources.
>>>>>
>>>>> Obviously the two brief examples above focus mostly on Camel, but the
>>>>> main problem is that I'm trying to figure out how I can no longer make
>>>>> everything provided in my bundle project provided scope without having to
>>>>> manually maintain the features files.
>>>>>
>>>>> That being said, I was looking at Apache Ace, but I'm not sure if
>>>>> using Apache Ace would cause it to be more work to do Karaf integration
>>>>> testing since Apache Ace doesn't use Karaf features.  I thought about maybe
>>>>> using OBR, but we use Artifactory and so I'm not sure if going down the OBR
>>>>> route might ultimately not be possible (I could be wrong but Artifactory
>>>>> doesn't appear to have OBR support), also I read that OSGi has moved away
>>>>> from OBR to different repository mechanism (forget offhand what it's
>>>>> called).  I looked into Apache Cave, but I don't want to rock the boat
>>>>> where I'm at yet since I'm the only one pushing Karaf and OSGi currently.
>>>>> I don't want to try to push things out of my organizations comfort zone by
>>>>> getting too radical in my project deployment.  I haven't gotten to read
>>>>> into the Karaf 4.0 profiles yet.
>>>>>
>>>>> What it really boils down to is that I'm not sure which deployment
>>>>> approach with Karaf would be the best to use out of all the options with
>>>>> the goal of moving to a continuous deployment model.
>>>>>
>>>>> Hoping someone might be willing to comment on how they solved these
>>>>> issues or maybe what direction I should look at going down that will allow
>>>>> me to improve these aspects.  It took me a while to get things where they
>>>>> are at, I want to be pretty confident in what path I go down next since if
>>>>> it doesn't pan out, it will be a lot of potentially wasted time and effort.
>>>>> :)
>>>>>
>>>>> Thanks in advance for any thoughts/suggestions.
>>>>>
>>>>> Ryan
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Apache Member
>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>> Committer & Project Lead
>>>> blog <http://notizblog.nierbeck.de/>
>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>
>>>> Software Architect / Project Manager / Scrum Master
>>>>
>>>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>


-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: Deploying applications on Karaf

[Ryan Moquin <fr...@gmail.com>]

Don't get me, features are a ton of help.  :)  I could maintain the
features myself, I just hate to have to keep two lists of dependencies.
The reason that the karaf maven plugin is a little tough sometimes is
because it's hard to make sure that you don't end up with bundles in a
generated feature that should come from a dependent feature without making
everything provided.  Making most of the dependencies provided makes it
hard to have transitive dependencies available in project dependencies
because they are marked provided in the other poms.  There is probably a
better way to handle it that I haven't figured out yet.  My project is
growing rapidly so I am trying to leverage whatever tools I can to keep my
features clean and not have to spend lots of time on them.

One thing I've been wrestling with (not sure if this has been improved in
Karaf 4)
is figuring out how to upgrade features and handle undeploying features..
I've played around with it but I guess I'm not sure I understand the proper
way to do it.  Such as if you had an application deployed in an environment
and wanted to upgrade a feature, do you have to install the new features
and uninstall the old one?  When I've tried to uninstall a feature
previously, it didn't seem like everything got removed.

I want want to be able to do incremental upgrades of my app but not sure
the best way to achieve that with features.  :)  I've done quite a lot of
research on it but haven't quite narrowed down a concrete way to do it (I
mean beyond manually upgrading individual bundles in the karaf console.)

Our Bamboo instance has access to the internet.  I think it hangs right at
the beginning of Pax Exam starting up.  It's such a pain to deal with our
Bamboo EC2 instance that I haven't been able to find out why it's hanging
yet.

Ryan
On Apr 12, 2015 2:34 AM, "Achim Nierbeck" <bc...@googlemail.com> wrote:

> Hi Ryan,
>
> see comments inline.
>
> regards, Achim
>
>
> 2015-04-12 0:37 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>
>> Thanks, Achim.  I am using a custom Karaf distribution, but maintaining
>> deployment flexibility using features feels a little tougher than it feels
>> like it should be (I don't have any better ideas).
>>
> That's strange, cause features are there to make life easier not harder.
> Make sure you cut the features right, not to big but also not to small
> (like one bundle, one feature). Usually it helps to create those feature
> files yourself as the plugin can't estimate what your intension of this
> combination of bundles is.
>
>
>>   I also have issues with my Karaf integration tests in Bamboo.  Paxexam
>> seems to not be able to initialize properly for who knows what reason.
>> Another problem is that I seem to run into a lot of problems in the tests
>> and can't seem to find anything in the output or Karaf love that
>> indicate.the problem.  If I run it normally in Karaf, I usually get clued
>> into what the issue is.
>>
> Now that could be addressed. First of all, does it work for you on your
> machine? Is Bamboo capable of connecting to the internet.
> Is maven capable of connecting to the required repositories. Do you have
> all dependencies defined in your POM, so the configuration section of the
> test does find those (combined with the depends-maven-plugin)
>
>
>> One last thing is that since my development shop uses MacOSx, Docker
>> containers have to be run in a VM which feels silly and is slow.  I don't
>> have a choice in that manner.
>>
> Oh, I'm working with MacOSx too. I know it can be cumbersome but running 4
> images in parallel can be done :-)
>
>
>
>> It would be nice if there was a way to manage feature xml files in a way
>> that felt more straight forward....  Maybe there is and I'm just not aware
>> of it.
>>
> You have the choices, use the karaf maven plugin for generation, or build
> those yourself. In the end it's up to how you want your application build.
> But maybe I miss something cause usually you have a certain set of bundles
> running in your application that need to run anyway. With this setup you
> can test your application.
>
>
>
>> On Apr 8, 2015 3:07 PM, "Achim Nierbeck" <bc...@googlemail.com> wrote:
>>
>>> Hi,
>>>
>>> just recently for a talk with showcase I was thinking about how to
>>> create a CI/CD build pipeline with Karaf. Maybe some of this does help
>>> you.[1]
>>> In the end I ended up with a setup where I have a pre-configured Karaf
>>> (custom build) which is startable as Docker Image or can be used as startup
>>> tar.gz of the Pax Exam integration tests.
>>> Usually camel routes are more about Integration therefore the most
>>> use-cases need to be handled by Integration tests. In those scenarios you
>>> just can't rely only on the camel-core bundles therefore you need more
>>> features just to have your unit tests/integration tests runnable. In those
>>> scenarios I usually suggest build your own distribution on top of Karaf and
>>> use it as your base-image in the pax-exam tests. If there is more external
>>> infrastructure needed I tend to use either full-integration test systems or
>>> now a docker based test-environment which can be started via a maven goal
>>> as pre-intergration phase systems.
>>>
>>> regards, Achim
>>>
>>> [1] - https://github.com/ANierbeck/JavaLang-Tooling
>>>
>>> 2015-04-08 17:24 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> I have another question regarding Karaf and deployments.  I was hoping
>>>> maybe some others could chime in on how they deal with the following
>>>> situation.
>>>>
>>>> I've been working on a fairly complex Karaf based application.  I'm
>>>> using features heavily to allow deploying the correct resources in
>>>> different environments (configuration and bundles).  I find it works very
>>>> well except for a couple situations:
>>>>
>>>> 1.  Unit testing.  It's hard to unit test things like camel routes
>>>> since I have ended up basically marking all bundle dependencies as provided
>>>> (in order to keep the created features files .  So if I try to unit test a
>>>> Camel route, transitive dependencies have to be directly added to the
>>>> project pom.
>>>>
>>>> 2.  I have all my configurations defined in a maven project for
>>>> assembling the final features xml file.  This of course doesn't make it
>>>> easy to use any of those configurations in camel integration tests since
>>>> configurations needed for config admin would have to be added to the
>>>> projects test resources.
>>>>
>>>> Obviously the two brief examples above focus mostly on Camel, but the
>>>> main problem is that I'm trying to figure out how I can no longer make
>>>> everything provided in my bundle project provided scope without having to
>>>> manually maintain the features files.
>>>>
>>>> That being said, I was looking at Apache Ace, but I'm not sure if using
>>>> Apache Ace would cause it to be more work to do Karaf integration testing
>>>> since Apache Ace doesn't use Karaf features.  I thought about maybe using
>>>> OBR, but we use Artifactory and so I'm not sure if going down the OBR route
>>>> might ultimately not be possible (I could be wrong but Artifactory doesn't
>>>> appear to have OBR support), also I read that OSGi has moved away from OBR
>>>> to different repository mechanism (forget offhand what it's called).  I
>>>> looked into Apache Cave, but I don't want to rock the boat where I'm at yet
>>>> since I'm the only one pushing Karaf and OSGi currently.  I don't want to
>>>> try to push things out of my organizations comfort zone by getting too
>>>> radical in my project deployment.  I haven't gotten to read into the Karaf
>>>> 4.0 profiles yet.
>>>>
>>>> What it really boils down to is that I'm not sure which deployment
>>>> approach with Karaf would be the best to use out of all the options with
>>>> the goal of moving to a continuous deployment model.
>>>>
>>>> Hoping someone might be willing to comment on how they solved these
>>>> issues or maybe what direction I should look at going down that will allow
>>>> me to improve these aspects.  It took me a while to get things where they
>>>> are at, I want to be pretty confident in what path I go down next since if
>>>> it doesn't pan out, it will be a lot of potentially wasted time and effort.
>>>> :)
>>>>
>>>> Thanks in advance for any thoughts/suggestions.
>>>>
>>>> Ryan
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>>> & Project Lead
>>> blog <http://notizblog.nierbeck.de/>
>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>
>>> Software Architect / Project Manager / Scrum Master
>>>
>>>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>

Re: Deploying applications on Karaf

[Achim Nierbeck <bc...@googlemail.com>]

Hi Ryan,

see comments inline.

regards, Achim


2015-04-12 0:37 GMT+02:00 Ryan Moquin <fr...@gmail.com>:

> Thanks, Achim.  I am using a custom Karaf distribution, but maintaining
> deployment flexibility using features feels a little tougher than it feels
> like it should be (I don't have any better ideas).
>
That's strange, cause features are there to make life easier not harder.
Make sure you cut the features right, not to big but also not to small
(like one bundle, one feature). Usually it helps to create those feature
files yourself as the plugin can't estimate what your intension of this
combination of bundles is.


>   I also have issues with my Karaf integration tests in Bamboo.  Paxexam
> seems to not be able to initialize properly for who knows what reason.
> Another problem is that I seem to run into a lot of problems in the tests
> and can't seem to find anything in the output or Karaf love that
> indicate.the problem.  If I run it normally in Karaf, I usually get clued
> into what the issue is.
>
Now that could be addressed. First of all, does it work for you on your
machine? Is Bamboo capable of connecting to the internet.
Is maven capable of connecting to the required repositories. Do you have
all dependencies defined in your POM, so the configuration section of the
test does find those (combined with the depends-maven-plugin)


> One last thing is that since my development shop uses MacOSx, Docker
> containers have to be run in a VM which feels silly and is slow.  I don't
> have a choice in that manner.
>
Oh, I'm working with MacOSx too. I know it can be cumbersome but running 4
images in parallel can be done :-)



> It would be nice if there was a way to manage feature xml files in a way
> that felt more straight forward....  Maybe there is and I'm just not aware
> of it.
>
You have the choices, use the karaf maven plugin for generation, or build
those yourself. In the end it's up to how you want your application build.
But maybe I miss something cause usually you have a certain set of bundles
running in your application that need to run anyway. With this setup you
can test your application.



> On Apr 8, 2015 3:07 PM, "Achim Nierbeck" <bc...@googlemail.com> wrote:
>
>> Hi,
>>
>> just recently for a talk with showcase I was thinking about how to create
>> a CI/CD build pipeline with Karaf. Maybe some of this does help you.[1]
>> In the end I ended up with a setup where I have a pre-configured Karaf
>> (custom build) which is startable as Docker Image or can be used as startup
>> tar.gz of the Pax Exam integration tests.
>> Usually camel routes are more about Integration therefore the most
>> use-cases need to be handled by Integration tests. In those scenarios you
>> just can't rely only on the camel-core bundles therefore you need more
>> features just to have your unit tests/integration tests runnable. In those
>> scenarios I usually suggest build your own distribution on top of Karaf and
>> use it as your base-image in the pax-exam tests. If there is more external
>> infrastructure needed I tend to use either full-integration test systems or
>> now a docker based test-environment which can be started via a maven goal
>> as pre-intergration phase systems.
>>
>> regards, Achim
>>
>> [1] - https://github.com/ANierbeck/JavaLang-Tooling
>>
>> 2015-04-08 17:24 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>>
>>> Hi,
>>>
>>> I have another question regarding Karaf and deployments.  I was hoping
>>> maybe some others could chime in on how they deal with the following
>>> situation.
>>>
>>> I've been working on a fairly complex Karaf based application.  I'm
>>> using features heavily to allow deploying the correct resources in
>>> different environments (configuration and bundles).  I find it works very
>>> well except for a couple situations:
>>>
>>> 1.  Unit testing.  It's hard to unit test things like camel routes since
>>> I have ended up basically marking all bundle dependencies as provided (in
>>> order to keep the created features files .  So if I try to unit test a
>>> Camel route, transitive dependencies have to be directly added to the
>>> project pom.
>>>
>>> 2.  I have all my configurations defined in a maven project for
>>> assembling the final features xml file.  This of course doesn't make it
>>> easy to use any of those configurations in camel integration tests since
>>> configurations needed for config admin would have to be added to the
>>> projects test resources.
>>>
>>> Obviously the two brief examples above focus mostly on Camel, but the
>>> main problem is that I'm trying to figure out how I can no longer make
>>> everything provided in my bundle project provided scope without having to
>>> manually maintain the features files.
>>>
>>> That being said, I was looking at Apache Ace, but I'm not sure if using
>>> Apache Ace would cause it to be more work to do Karaf integration testing
>>> since Apache Ace doesn't use Karaf features.  I thought about maybe using
>>> OBR, but we use Artifactory and so I'm not sure if going down the OBR route
>>> might ultimately not be possible (I could be wrong but Artifactory doesn't
>>> appear to have OBR support), also I read that OSGi has moved away from OBR
>>> to different repository mechanism (forget offhand what it's called).  I
>>> looked into Apache Cave, but I don't want to rock the boat where I'm at yet
>>> since I'm the only one pushing Karaf and OSGi currently.  I don't want to
>>> try to push things out of my organizations comfort zone by getting too
>>> radical in my project deployment.  I haven't gotten to read into the Karaf
>>> 4.0 profiles yet.
>>>
>>> What it really boils down to is that I'm not sure which deployment
>>> approach with Karaf would be the best to use out of all the options with
>>> the goal of moving to a continuous deployment model.
>>>
>>> Hoping someone might be willing to comment on how they solved these
>>> issues or maybe what direction I should look at going down that will allow
>>> me to improve these aspects.  It took me a while to get things where they
>>> are at, I want to be pretty confident in what path I go down next since if
>>> it doesn't pan out, it will be a lot of potentially wasted time and effort.
>>> :)
>>>
>>> Thanks in advance for any thoughts/suggestions.
>>>
>>> Ryan
>>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>


-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: Deploying applications on Karaf

[Ryan Moquin <fr...@gmail.com>]

Thanks, Achim.  I am using a custom Karaf distribution, but maintaining
deployment flexibility using features feels a little tougher than it feels
like it should be (I don't have any better ideas).  I also have issues with
my Karaf integration tests in Bamboo.  Paxexam seems to not be able to
initialize properly for who knows what reason.  Another problem is that I
seem to run into a lot of problems in the tests and can't seem to find
anything in the output or Karaf love that indicate.the problem.  If I run
it normally in Karaf, I usually get clued into what the issue is.

One last thing is that since my development shop uses MacOSx, Docker
containers have to be run in a VM which feels silly and is slow.  I don't
have a choice in that manner.

It would be nice if there was a way to manage feature xml files in a way
that felt more straight forward....  Maybe there is and I'm just not aware
of it.
On Apr 8, 2015 3:07 PM, "Achim Nierbeck" <bc...@googlemail.com> wrote:

> Hi,
>
> just recently for a talk with showcase I was thinking about how to create
> a CI/CD build pipeline with Karaf. Maybe some of this does help you.[1]
> In the end I ended up with a setup where I have a pre-configured Karaf
> (custom build) which is startable as Docker Image or can be used as startup
> tar.gz of the Pax Exam integration tests.
> Usually camel routes are more about Integration therefore the most
> use-cases need to be handled by Integration tests. In those scenarios you
> just can't rely only on the camel-core bundles therefore you need more
> features just to have your unit tests/integration tests runnable. In those
> scenarios I usually suggest build your own distribution on top of Karaf and
> use it as your base-image in the pax-exam tests. If there is more external
> infrastructure needed I tend to use either full-integration test systems or
> now a docker based test-environment which can be started via a maven goal
> as pre-intergration phase systems.
>
> regards, Achim
>
> [1] - https://github.com/ANierbeck/JavaLang-Tooling
>
> 2015-04-08 17:24 GMT+02:00 Ryan Moquin <fr...@gmail.com>:
>
>> Hi,
>>
>> I have another question regarding Karaf and deployments.  I was hoping
>> maybe some others could chime in on how they deal with the following
>> situation.
>>
>> I've been working on a fairly complex Karaf based application.  I'm using
>> features heavily to allow deploying the correct resources in different
>> environments (configuration and bundles).  I find it works very well except
>> for a couple situations:
>>
>> 1.  Unit testing.  It's hard to unit test things like camel routes since
>> I have ended up basically marking all bundle dependencies as provided (in
>> order to keep the created features files .  So if I try to unit test a
>> Camel route, transitive dependencies have to be directly added to the
>> project pom.
>>
>> 2.  I have all my configurations defined in a maven project for
>> assembling the final features xml file.  This of course doesn't make it
>> easy to use any of those configurations in camel integration tests since
>> configurations needed for config admin would have to be added to the
>> projects test resources.
>>
>> Obviously the two brief examples above focus mostly on Camel, but the
>> main problem is that I'm trying to figure out how I can no longer make
>> everything provided in my bundle project provided scope without having to
>> manually maintain the features files.
>>
>> That being said, I was looking at Apache Ace, but I'm not sure if using
>> Apache Ace would cause it to be more work to do Karaf integration testing
>> since Apache Ace doesn't use Karaf features.  I thought about maybe using
>> OBR, but we use Artifactory and so I'm not sure if going down the OBR route
>> might ultimately not be possible (I could be wrong but Artifactory doesn't
>> appear to have OBR support), also I read that OSGi has moved away from OBR
>> to different repository mechanism (forget offhand what it's called).  I
>> looked into Apache Cave, but I don't want to rock the boat where I'm at yet
>> since I'm the only one pushing Karaf and OSGi currently.  I don't want to
>> try to push things out of my organizations comfort zone by getting too
>> radical in my project deployment.  I haven't gotten to read into the Karaf
>> 4.0 profiles yet.
>>
>> What it really boils down to is that I'm not sure which deployment
>> approach with Karaf would be the best to use out of all the options with
>> the goal of moving to a continuous deployment model.
>>
>> Hoping someone might be willing to comment on how they solved these
>> issues or maybe what direction I should look at going down that will allow
>> me to improve these aspects.  It took me a while to get things where they
>> are at, I want to be pretty confident in what path I go down next since if
>> it doesn't pan out, it will be a lot of potentially wasted time and effort.
>> :)
>>
>> Thanks in advance for any thoughts/suggestions.
>>
>> Ryan
>>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>

Re: Deploying applications on Karaf

[Achim Nierbeck <bc...@googlemail.com>]

Hi,

just recently for a talk with showcase I was thinking about how to create a
CI/CD build pipeline with Karaf. Maybe some of this does help you.[1]
In the end I ended up with a setup where I have a pre-configured Karaf
(custom build) which is startable as Docker Image or can be used as startup
tar.gz of the Pax Exam integration tests.
Usually camel routes are more about Integration therefore the most
use-cases need to be handled by Integration tests. In those scenarios you
just can't rely only on the camel-core bundles therefore you need more
features just to have your unit tests/integration tests runnable. In those
scenarios I usually suggest build your own distribution on top of Karaf and
use it as your base-image in the pax-exam tests. If there is more external
infrastructure needed I tend to use either full-integration test systems or
now a docker based test-environment which can be started via a maven goal
as pre-intergration phase systems.

regards, Achim

[1] - https://github.com/ANierbeck/JavaLang-Tooling

2015-04-08 17:24 GMT+02:00 Ryan Moquin <fr...@gmail.com>:

> Hi,
>
> I have another question regarding Karaf and deployments.  I was hoping
> maybe some others could chime in on how they deal with the following
> situation.
>
> I've been working on a fairly complex Karaf based application.  I'm using
> features heavily to allow deploying the correct resources in different
> environments (configuration and bundles).  I find it works very well except
> for a couple situations:
>
> 1.  Unit testing.  It's hard to unit test things like camel routes since I
> have ended up basically marking all bundle dependencies as provided (in
> order to keep the created features files .  So if I try to unit test a
> Camel route, transitive dependencies have to be directly added to the
> project pom.
>
> 2.  I have all my configurations defined in a maven project for assembling
> the final features xml file.  This of course doesn't make it easy to use
> any of those configurations in camel integration tests since configurations
> needed for config admin would have to be added to the projects test
> resources.
>
> Obviously the two brief examples above focus mostly on Camel, but the main
> problem is that I'm trying to figure out how I can no longer make
> everything provided in my bundle project provided scope without having to
> manually maintain the features files.
>
> That being said, I was looking at Apache Ace, but I'm not sure if using
> Apache Ace would cause it to be more work to do Karaf integration testing
> since Apache Ace doesn't use Karaf features.  I thought about maybe using
> OBR, but we use Artifactory and so I'm not sure if going down the OBR route
> might ultimately not be possible (I could be wrong but Artifactory doesn't
> appear to have OBR support), also I read that OSGi has moved away from OBR
> to different repository mechanism (forget offhand what it's called).  I
> looked into Apache Cave, but I don't want to rock the boat where I'm at yet
> since I'm the only one pushing Karaf and OSGi currently.  I don't want to
> try to push things out of my organizations comfort zone by getting too
> radical in my project deployment.  I haven't gotten to read into the Karaf
> 4.0 profiles yet.
>
> What it really boils down to is that I'm not sure which deployment
> approach with Karaf would be the best to use out of all the options with
> the goal of moving to a continuous deployment model.
>
> Hoping someone might be willing to comment on how they solved these issues
> or maybe what direction I should look at going down that will allow me to
> improve these aspects.  It took me a while to get things where they are at,
> I want to be pretty confident in what path I go down next since if it
> doesn't pan out, it will be a lot of potentially wasted time and effort. :)
>
> Thanks in advance for any thoughts/suggestions.
>
> Ryan
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master