Do you have pointers about those "application bundles" ? 2015-11-26 10:59 GMT+01:00 David Leangen <apa...@leangen.net>:
> > I have written down some ideas here some time ago: > > 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 > > >
