So in the end it looks like Karaf-Boot with profiles, as I tried some long time ago :) would be the best match to what I've seen so far in this thread.
The idea I had at the time would be to actually merge those static profiles with a maven plugin generating the static Karaf assembly via the maven plugin. All of the idea-scratch-start stuff can be found at JBs github project. Haven't had the time to get going on it any further, just been an idea in a seperate branch at the time: https://github.com/jbonofre/karaf-boot/tree/profiles/karaf-boot-starters/karaf-boot-starter-web/src/main/resources/META-INF/profiles regards, Achim 2017-01-12 16:18 GMT+00:00 Nick Baker <[email protected]>: > I do agree that an "opinionated" or "prescriptive" stack would help. It > shouldn't prohibit the usage of any Karaf feature of course. > > > New users gravitate to full-stack solutions. Agnostic platforms with lots > of options and no predefined stack, while obviously having many merits and > longer legs (don't be Wicket), just haven't been winning out in adoption. > This applies across the spectrum of computing. > > ------------------------------ > *From:* Brad Johnson <[email protected]> > *Sent:* Thursday, January 12, 2017 10:46:55 AM > *To:* [email protected] > *Subject:* RE: Levels of Containerization - focus on Docker and Karaf > > > Guillaume, > > > > I’d mentioned that in an early post as my preferred way to do > microservices and perhaps a good way of doing a Karaf Boot. I’ve worked > with the Karaf 4 profiles and they are great. Also used your CDI OSGi > service. If we could use the Karaf 4 profiles with the CDI implementation > with OSGi services and the Camel Java DSL as a standard stack, it would > permit focused development and standardized bundle configurations. > > > > When I created a zip with Karaf, CXF and Camel the footprint was 30MB. > > > > While having Karaf Boot support DS, Blueprint, CDI, etc. I’m not sure > that’s the healthiest move to encourage adoption. We need less > fragmentation in the OSGi world and not more. Obviously even if Karaf Boot > adopts one as the recommended standard it doesn’t mean that the others > can’t be used. When reading through Camel documentation on-line, for > example, the confusion such fragmentation brings is obvious. One becomes > adept at converting Java DSL to blueprint or from blueprint to the Java DSL > in one’s mind. > > > > The static profiles work great and will let us create a number of > standardized appliances for a wide variety of topology concerns and not > just for microservices. A “switchboard” appliance, for example, might be > used for orchestrating microservices and managing the APIs. A “gateway” > appliance might have standard JAAS, web service configuration and a routing > mechanism for calling microservices. An “AB” appliance could be used for > 80/20 testing. And so on. Take the idea of enterprise integration > patterns and bring it up to enterprise integration patterns using Karaf > appliances. > > > > Many appliances might be “sealed”. An appliance for AB testing, for > example, would have configuration for two addresses in the configuration > file and a percentage of traffic going to each. Non need to actually > program or re-program the internals any more than we’d usually re-program a > Camel component. But the source would be there if one wanted to create a > new component or modify how an existing one functioned. > > > > I’d vote for using CDI along with the Camel Java DSL for a couple of > reasons. The first would be the standardization and portability of both > code and skills. Using CDI would mean that any Glassfish, JBoss, etc. > developer would feel comfortable using the code. Using Java Camel DSL > would be for the same reason. It would also give a programmer a sense that > if they give Karaf Boot with the static profiles a shot, they aren’t locked > in but can easily move to a different stack if necessary. In a sense this > is the same reason that Google chose Java language to run on the DVM. It > tapped into a large existing skillbase instead of trying to get the world > to adopt and learn a new language. CDI with OSGi extensions also allows > developers to use one paradigm for everything from lashing up internal > dependency injections to working with OSGi services. I believe when you put > that CDI extension out there you used blueprint style proxies under the > cover. As a developer using the CDI OSGi extension it was transparent to > me. If you later decided to rework that as a DS service, it would remain > transparent and very much in the whole spirit of OSGi and its mechanisms > for allowing refactoring and even rewriting without breaking the world. It > also makes unit testing a snap. Any of us who have wrestled with Camel > Blueprint Test Support can appreciate that. > > > > This would also permit for standardization of documentation and of Karaf > Boot appliance project structures and Maven plug-in use. A bit of > convention over configuration. Projects would have a standard > configuration.cfg file that gets deployed via features to the pid.cfg. A > standard features file in the filtered folder. Those already exist, of > course, but it isn’t as standardized as it could be. > > > > Personally I think this sort of goal with CDI, Karaf 4 and its profiles, > and Camel Java DSL should be accelerated since Spring Boot is already out > there. Waiting for another couple of years to release this as a standard > might be too late. > > > > The pieces are already there so it isn’t like we’d have to start from > scratch. This would also play well with larger container concerns like > Docker and Kubernettes. > > > > Brad > > > > *From:* Guillaume Nodet [mailto:[email protected]] > *Sent:* Thursday, January 12, 2017 4:55 AMJ > *To:* user <[email protected]> > *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/ > > > -- 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
