> I have written down some ideas here some time ago:
> http://liquid-reality.de/display/liquid/Design+repository+based+features+for+Apache+Karaf
>
> <http://liquid-reality.de/display/liquid/Design+repository+based+features+for+Apache+Karaf>
Very nice !
> I agree we would need to also bring the features into the OBR at some point.
> Karaf already uses a special capability to describe features internally to
> feed the resolver. We should be able to extend and standardize this.
Great!
Currently, when I deploy bundles from the dev environment, if I also need a
features.xml file, then it needs to be shipped together with the OBR as part of
my deployment package. My repo then looks something like this:
index.xml
index.xml.sha
features.xml
com.foo.bar/
…
It seems odd to me, and not DRY, that both index.xml and features.xml are
provided in the same place like this. They seem to have very similar functions.
So folding these into the OBR itself sounds right to me.
>> I believe that OSGi presumes that the bundle developer is a different role
>> from the operator. I would argue that the creation of features is an
>> operator function, not a bundle developer function.
> Normally an operator/admin does not want to be too much involved into the
> definition of the features.
I do not disagree!
> So I think this should be part of the development process. The operator would
> be just given the deployment unit with the instructions how to install it.
Perhaps, but I am not so sure.
I can envision, for instance, configuration parameters on 3 levels:
1) default parameters (probably provided in the code)
* reasonable defaults for a generalised environment
* coded by the developer
2) default parameters for a specific installation / runtime
* system values for that particular environment
* provided by the developer, IF the developer is part of the same team
3) maintenance or operational parameters
* stuff the operator needs to do to get and keep a system running
* likely related to a particular machine (IP address, port numbers, disk
usage…)
We are also toying with the idea of a “user operator” (kind of a support
person, but who interfaces with the OSGi system) or something like that,
meaning somebody who can install new users, help users fix problems during
runtime, and so on.
The more expertise these operators require (such as OSGi / bundle-level
knowledge) the costlier the system becomes.
To get back to the point… enRoute/bndtools seems to promote the idea of an
“application bundle”, which pulls in all the required dependencies. If this
bundle already provides everything I need to get a “feature” (in the general
sense) up and running, then why all the extra cruft around it? All I need to do
is detect this “application bundle(s)” in my OBR, and I can just pull in the
other requirements. No?
Ok, instead of making a fool of myself on this list, maybe I should try out my
ideas in the code first as a proof of concept. :-)
Cheers,
=David
