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
