Things are working there way there with bndtools with bndrun files. You can see a couple karaf libraries used in Christians chat sample https://github.com/cschneider/osgi-chat The new cxf libraries also have bndrun samples. Not everything in karaf can be generated in bndrun at this time but I think some libraries are coming on to it. If you are interested in that I would checkout the bndtools maven integrations in the more recent releases.
On Fri, Jan 13, 2017 at 3:14 PM, Brad Johnson <[email protected]> wrote: > Interesting concept. That would be interesting to see. > > > > *From:* Dario Amiri [mailto:[email protected]] > *Sent:* Friday, January 13, 2017 2:11 PM > > *To:* [email protected] > *Subject:* Re: Levels of Containerization - focus on Docker and Karaf > > > > Ideally, I want to be able to do: > > java -jar my-karaf.jar > > And I can override individual configuration files using some environment > variable convention. > > D > > > > On 01/13/2017 11:56 AM, Brad Johnson wrote: > > Does it have to be an executable jar file or just a standalone executable? > The static profiles actually create and zip up a full > Karaf/felix/dependency/application implementation that when unzipped has > all the standard bin directory items. > > > > Brad > > > > *From:* Dario Amiri [mailto:[email protected] > <[email protected]>] > *Sent:* Friday, January 13, 2017 1:28 PM > *To:* [email protected] > *Subject:* Re: Levels of Containerization - focus on Docker and Karaf > > > > I use Docker and Karaf. I've never had a problem creating a Docker image > of my Karaf container. What I gain is freedom from having to worry about > dependency related issues such as whether the right JRE is available. > > > > That being said there are some challenges when using Karaf to build > 12-factor apps. FWIW here's my two item list of what would make Karaf a > more attractive platform from a 12-factor app perspective. > > > > 1. The ability to inject Karaf configuration through the environment (e.g. > environment variables). Not just a single property, but an entire config > admin managed configuration file if necessary. Even the existing support > for reading property values from the environment is cumbersome because it > requires having to setup that relationship as a Java system property as > well. > > 2. The ability to package Karaf as a standalone runnable jar. Looks like > Karaf boot is addressing this. I hope it comes with tooling that makes it > easy to transition to this kind of model. > > > > D > > > > On 01/12/2017 04:44 AM, Nick Baker wrote: > > Thanks Guillaume! > > > > This is perfect for our microservice/containerized Karaf. I'll give this a > try and see if we can get our features in startup. We've had issues in the > past here. > > > > -Nick Baker > ------------------------------ > > *From:* Guillaume Nodet <[email protected]> <[email protected]> > *Sent:* Thursday, January 12, 2017 5:55:24 AM > *To:* user > *Subject:* Re: Levels of Containerization - focus on Docker and Karaf > > > > Fwiw, starting with Karaf 4.x, you can build custom distributions which > are mostly static, and that more closely map to micro-services / docker > images. The "static" images are called this way because you they kinda > remove all the OSGi dynamism, i.e. no feature service, no deploy folder, > read-only config admin, all bundles being installed at startup time from > etc/startup.properties. > > This can be easily done by using the karaf maven plugin and configuring > startupFeatures and referencing the static kar, as shown in: > > https://github.com/apache/karaf/blob/master/demos/ > profiles/static/pom.xml > > > > > > 2017-01-11 21:07 GMT+01:00 CodeCola <[email protected]>: > > Not a question but a request for comments. With a focus on Java. > > Container technology has traditionally been messy with dependencies and no > easy failsafe way until Docker came along to really pack ALL dependencies > (including the JVM) together in one ready-to-ship image that was faster, > more comfortable, and easier to understand than other container and code > shipping methods out there. The spectrum from (Classical) Java EE > Containers > (e.g. Tomcat, Jetty) --> Java Application Servers that are containerized > (Karaf, Wildfly, etc), Application Delivery Containers (Docker) and > Virtualization (VMWare, Hyper-V) etc. offers a different level of isolation > with different goals (abstraction, isolation and delivery). > > What are the choices, how should they play together, should they be used in > conjunction with each other as they offer different kinds of > Containerization? > > <http://karaf.922171.n3.nabble.com/file/n4049162/ > Levels_of_Containerization.png> > > > > -- > View this message in context: http://karaf.922171.n3.nabble.com/Levels-of- > Containerization-focus-on-Docker-and-Karaf-tp4049162.html > Sent from the Karaf - User mailing list archive at Nabble.com. > > > > > > -- > > ------------------------ > Guillaume Nodet > ------------------------ > > Red Hat, Open Source Integration > > > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > > > > > >
