Christian, I think your idea of the OBR repository for features and profiles is good. I think when I start using karaf-boot what I'd certainly want is a way to specify features almost like recipes. Those would obviously have to be inlined in the bundles features file as their true mvn:group/artifact/version form since everything at that point is static. We needn't have a look up mechanism at runtime obviously. In similar fashion one could have a plugin look at the POM and dependencies specified as being required for running the bundle and have those installed. Unfortunately I don't know how Karaf-boot is going to install those. In lib? endorsed? I'd think there would be a number of possible ways to add those and the static nature will simplify much of it.
Brad On Mon, Apr 18, 2016 at 2:29 AM, Christian Schneider < [email protected]> wrote: > I am not very familiar with the concept of profiles till now. Guillaume > explained it a bit to me but honestly I hope we do not need it too often. > An OSGi application should be mainly built out of bundles and profiles > concentrate more on the non OSGi static files in karaf. > > The main part of the packaging in karaf boot is to resolve features at > build time. It uses the static profile but nothing else from the profiles > concept. This part already works. I have created such a packaging for the > tasklist-ds example: > https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app > > The second part. The karaf boot development model is still in the making > but you can already use the packaging if you want. > > About features and poms you are right. You have to maintain two sets of > dependencies but this is just a result of the fact that OSGi resolves > differently from maven. So this never will completely go away. What we > could do with a pom is create an obr repository. This could then be used to > back a feature repo. So currently in a feature we have to list all the > bundles, with a backing obr repo we could instead only list some > requirements (like top level bundles) and resolve the rest. > > I have prototyped such a packaging using bndtools as it already has the > OBR resolving: > https://github.com/cschneider/bndtools-tutorials/tree/master/tasklist-ds > The creation of the repository went quite smoothly as eclipse m2e provides > nice tooling to define the pom and the necessary excludes. > Defining the requirements in bndtools also works really nicely as they got > a good UI for it. > > Unfortunately bndtools does not know about features. So while this > approach is better than defining each single bundle of an application it is > not really better than the karaf approach were you define most of your deps > as features. So this would only be really useable once we have both > features and a backing obr repo. > > Another thing that I found bndtools is lacking is all the preparation > karaf already has for some of the more complicated features like > tansactions and cxf. There it is not enough to just install bundles. > You also have to fiddle with the boot path for transactions and some java > se spec nightmares in the case of cxf. So these are the regions where karaf > really helps. > > Christian > > On 18.04.2016 07:24, Brad Johnson wrote: > >> Christian, >> >> I just re-read your section on the static profiles. That makes sense. I >> could see this becoming like puppet/chef sort of recipes or even like the >> way Docker allows building up of images. Not that I know those that well. >> I use features all the time of course but see huge advantage to making that >> a bundle time set of static steps instead of the current runtime usage. >> Not that the current use is bad, mind you, its context is different and >> slimming down the karaf core by eliminating that management overhead would >> be good for something like karaf-boot. In the current monolithic >> enterprise environment it makes sense to have stacks of features available >> to load when necessary. The static mechanism would get rid of that. But it >> would also permit building up a centralized registry or library of features >> that one could leverage by adding into a boot recipe of some sort. Maybe >> we'd get the quick flexibility for creating projects that archetypes always >> seemed to promise but never quit seemed to manage. >> >> One item that has always bothered me about features is they are >> orthogonal to but replicate much of what goes into a POM. One ends up >> with two sets of dependency management mechanisms that have never really >> dovetailed. It would be nice if we had a Maven plugin that could look at >> the dependencies in a POM and create a static feature profile or at least >> give a good guess at what they should be while allowing for some tweaking. >> Perhaps since the karaf-boot environment is static and doesn't rely on or >> expect another environment to provide dependencies that would be easier to >> accomplish. >> >> Funny how Moore's law took a sideways turn on us. Now we don't have the >> ever increasing clock speed but we have cores coming out our ears and RAM >> and disk space in abundance. A little fatness in our deployments is an >> acceptable trade off now. >> >> Brad >> >> > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
