When I think of how I'd imagine a "repository" for a static bundle creation system like for karaf-boot I'd only want the definitions of the feature set and not the actual uber bundles. In other words, I'd want to be able to specify some feature with version number and have the contents merged into my bundle's feature set (much like an effective POM does) and then written out at which point the individual artifacts could be retrieved and included in karaf-boot bundle. That would also let me hand tweak it if necessary later (if a couple of features specified conflicting or unnecessary extra versions of the same group/artifact). Essentially then any list of features and bundles would get flattened into a list for inclusion in, where, lib?
I'm sure you've all thought this through much more thoroughly since I'm coming into it with little actual knowledge of karaf-boot (or spring boot for that matter). I can say I'm very much looking forward to the karaf-boot and the flexibility it will offer as well as the challenges. Brad On Mon, Apr 18, 2016 at 12:16 PM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Right now, the features XML can already define a OBR repository. > > I don't think the opposite makes sense and solve the problem. It's > something that we already discussed, but I'm not convince driving all with > OBR repo (the new name is Bundle Repository ;)) will be so good. It will be > a mess IMHO and we will have some missing parts compared to features. I > worked in Apache ACE (mostly focused on OBR repository and deploy admin), > and parts are missing when dealing with more than simple bundles. > > Regards > JB > > On 04/18/2016 05:54 PM, Brad Johnson wrote: > >> 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 >> <ch...@die-schneider.net <mailto:ch...@die-schneider.net>> 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 >> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
