I second Achim here: we did Cave exactly to easily provide maven and OBR
repositories server !
RegardsJB
Sent from my Samsung device
-------- Original message --------
From: Achim Nierbeck <bcanh...@googlemail.com>
Date: 16/04/2015 00:12 (GMT+01:00)
To: user@karaf.apache.org
Subject: Re: Deploying applications on Karaf
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 <fragility...@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 <fragility...@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" <bcanh...@googlemail.com> wrote:
Hi Ryan,
see comments inline.
regards, Achim
2015-04-12 0:37 GMT+02:00 Ryan Moquin <fragility...@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" <bcanh...@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 <fragility...@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
