I agree with Christian.
We already have a Jira about that as Christian and I discussed about that.
The purpose is to first have repository/index XML references in a
features XML.
Regards
JB
On 11/26/2015 09:52 AM, Christian Schneider wrote:
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>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"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">
<directivename="filter"value="(&(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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
