Am 26.11.2015 um 10:59 schrieb David Leangen:
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…)
What you describe is a typical configuration problem especially when
having different evnvironments like dev, test, prod which is absolutely
common. Karaf does not yet provide a full solution for this. You can
already provide default configs but it is still difficult to express
what needs to be configured for the different environments. On the other
hand I think that these configs have a different lifecycle than the
application code. So I think it needs to be handled separately from
features.
I have scoped such a scenario a long time ago here:
http://liquid-reality.de/display/liquid/Software+Development+and+Deployment
This is just an overview of the problem though and does not provide an
actual solution.
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?
Not sure about the application bundle. What I saw is that bndtools uses
the bndrun file to define the requirements for the resolver.
I agree that in the application case features are not absolutely
required. In fact I talked to Peter Kriens at eclipsecon about it and he
is not yet convinced that features are needed.
I have also done some tests in bndtools and was able to get cxf as well
as jpa + hibernate running just with a obr repo and a bndrun file. The
list of bundles / requirements I needed to define was not that big.
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.
Christian
