Just a few points I want to mention in this discussion.
The karaf deployer uses the OSGi resolver. Features are modelled into
OSGi resources, the exact same way as bundles, so they can easily be
written with the standard xml description. It's just a matter of
writing back resource generated from the feature as an xml (and the
code already exists).
See
https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/resolver/FeatureResource.java#L48-L71
I agree the xml repository would be better placed as a top level
element, along feature repositories.
As for deployment, I haven't seen how "bnd applications" are modelled,
but the karaf deployer can be given abstract requirements. When one
installs a feature, it's simply translated into a new requirement that
point to this feature.
https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/resolver/ResourceUtils.java#L169-L180
Guillaume
2015-11-26 9:52 GMT+01:00 Christian Schneider <[email protected]
<mailto:[email protected]>>:
On 26.11.2015 08:52, David Leangen wrote:
Then perhaps all we need to do is allow a Feature to include an
OBR repo as an option.
Bundles in the feature could provide a capability (for example in
the “namespace=karaf.feature”) to flag it as a bundle to be
included in the feature.
<featuresxmlns="http://karaf.apache.org/xmlns/features/v1.3.0"name=“my-feature-set";>
<featurename=“my-feature"description=“My Feature"version=“1.0.0">
**
*<obr>http://host.com/path/to/repo/index.xml</obr>*
</feature>
</features>
I think it would make more sense to have the obr element on top
level of the features xml as I think the obr repository would be
that basis of all the features in the file.
I have written down some ideas here some time ago:
http://liquid-reality.de/display/liquid/Design+repository+based+features+for+Apache+Karaf
Ideally we should work together on a complete design in an apache
wiki so all can help.
And in the OBR:
<repositoryxmlns="http://www.osgi.org/xmlns/repository/v1.0.0"increment=“1"name="Release";>
<resource>
<capabilitynamespace="osgi.identity">
<attributename="osgi.identity"value=“my.application.api"/>
<attributename="type"value="osgi.bundle"/>
<attributename="version"type="Version"value=“1.0.0"/>
</capability>
<capabilitynamespace="osgi.content">
<attributename="osgi.content"value=“..."/>
<attributename="url"value=“..."/>
<attributename="size"type="Long"value=“..."/>
<attributename="mime"value="application/vnd.osgi.bundle"/>
</capability>
<capabilitynamespace="osgi.wiring.bundle">
<attributename="osgi.wiring.bundle"value=“my.dependency"/>
<attributename="bundle-version"type="Version"value=“1.0.0"/>
</capability>
...
*<capabilitynamespace=“karaf.feature">*
**
*<attributename=“feature.id
<http://feature.id>"value=“name.of.feature/1.0.0"/>*
**
*<attributename=“start-level"value=“80"/>*
**
*<attributename=“config"value=“com.foo.bar”>*
* <property name=“myProperty” value=“myValue”/>*
*</attribute>*
**
*</capability>*
<requirementnamespace="osgi.ee <http://osgi.ee>">
<directivename="filter"value="(&(osgi.ee
<http://osgi.ee>=JavaSE)(version=1.8))"/>
</requirement>
...
</resource>
</repository>
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.
As karaf features are proprietary we might be able to use
subsystem descriptors (in their feature mode). In fact they look a
lot like bndrun files already. So maybe the subsystem spec could
be enhanced to cover that case.
(Not sure if the attributes should be there or not, just added
them in as an afterthought.)
In any case, all the bundle information etc. is already there, so
it seems unnecessary to have to duplicate it in in a features.xml
file.
I think it would not be a good idea to use an OBR repository to
describe a feature. An OBR repository is more like the target
platform in eclipse PDE. It defines which bundles are available
and what they provide and need.
The feature should then define the requirements to help the
resolver decide which bundles from the repository to combine to
make the feature resolvable. This is then very similar to a bndrun
file.
The main question here is how to define that a feature might
depend on another feature. Bndtools currently does not have this
concept in its bndrun files. I think one possibility would be to
define such a dependency as a requirement on a feature.
As bndtools is a design/development time, I would prefer that
it can generate a complete feature.
For the application mode a it makes sense that bndtools creates a
complete deployment (probably even including the needed karaf
internal features). For the server mode the features would be just
requirements + refrence to
OBR repository and the karaf resolver would build the actual list
of bundles at runtime.
I understand.
This does not really fit our model well and, if I am
understanding the intent of OSGi, not that model, either.
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. 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.
In my specific use case, I am considering having a “deployment”
service read the available OBR repositories, and provide
deployment options to the operator at (deployment) runtime. What
I think would be easy to do is to read the OBR repositories and,
one way or another, create features on the fly based on what is
available. In this way, the operator creates the features (on the
fly) based on what she is given by the bundle developers. This
way, there would be a clear handoff (the OBR repo being the
intermediary), strong decoupling between development and runtime,
and a clear distinction of roles.
The features themselves can not be created on the fly as you need
to define their requirements manually. The list of actual bundles
to deploy can be created on the fly though. In fact we are not
even that far away from this scenario.
What I already tried way:
1. Create an obr repository from a pom using the
bnd-indexer-plugin and deploy it to maven
2. Add the obr repository to karaf using obr:url-add mvn:<maven
uri of the index>
3. Create a feature that just defines some top level bundles as
requirements for the resolver
4. Install the feature
This already worked half way. The karaf feature service and
resolver was able to look one level deep into the obr repo and
auto install the bundles that were directly needed by the bundles
I defined in the feature.
Unfortunately transitive dependencies further down were not
considered. Probably this is a bug in the feature service or
resolver. I will create an example project and issue so we can
solve this.
So apart from the issue I had the only critical thing missing is
that I can reference the obr repo in the feature.xml.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
