>> I can envision, for instance, configuration parameters on 3 levels: >> >> 1) default parameters (probably provided in the code) >> 2) default parameters for a specific installation / runtime >> 3) maintenance or operational parameters > > I have scoped such a scenario a long time ago here: > http://liquid-reality.de/display/liquid/Software+Development+and+Deployment > <http://liquid-reality.de/display/liquid/Software+Development+and+Deployment>
Yes, I think this is quite similar. :-) > Not sure about the application bundle. What I saw is that bndtools uses the > bndrun file to define the requirements for the resolver. From the enRoute website: http://enroute.osgi.org/tutorial_base/700-deploy.html <http://enroute.osgi.org/tutorial_base/700-deploy.html> A bndrun file [...] allows us to specify a runtime for our framework. Also, closer to the end: How Does it Work? bndrun files define the requirements on a desired runtime. When the Resolve button is hit, the bnd resolver looks at the initial requirements and will try to find resources in the repositories that together match those requirements and the requirements from the introduced resources. The resulting set of bundles defines a runtime, these bundles are set in the -runbundles instruction. A runtime environment can then be executed to verify it, potentially resulting in some modifications. If the result is ok, then the export function of bnd is used. The bnd export goes through a plugin; this is the same plugin that manages the launching. In this case this is the default aQute.launch plugin. The plugin takes the runtime environment and creates a JAR that contains all the dependencies, including itself and any properties; creating a JAR that is completely self contained. This corresponds to how I use it. The dependencies are defined in the application bundle via annotations, and a default configuration is also provided in the bundle. All the bndrun file is is an index of the results of what happens when you hit “resolve”. My understanding is that Karaf IS the runtime, and can do the resolution at runtime, so there is really no need for a bndrun file. Where I can see the plugin being useful, though, is if you want to run Karaf directly in the Eclipse container. Otherwise, the runtime descriptor could just as easily be generated at runtime, provided of course there is enough information available to generate it. > On the other hand features can define things that you might overlook when > just using a bndrun file. So for example CXF would like to replace certain > jdk built in specs and impls for security or performance reasons. These > things are more difficult to express in the form of a bndrun file. Yes, agree. For this, some extension mechanism would be required in addition to the OBR + requirements. As you mentioned previously, eventually if this were part of the OBR spec, it would be ideal. Cheers, =David
