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]>: > 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. > > <features xmlns="http://karaf.apache.org/xmlns/features/v1.3.0"; name=“ > my-feature-set"> > <feature name=“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 > <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: > > <repository xmlns="http://www.osgi.org/xmlns/repository/v1.0.0"; increment > =“1" name="Release"> > <resource> > <capability namespace="osgi.identity"> > <attribute name="osgi.identity" value=“my.application.api"/> > <attribute name="type" value="osgi.bundle"/> > <attribute name="version" type="Version" value=“1.0.0"/> > </capability> > <capability namespace="osgi.content"> > <attribute name="osgi.content" value=“..."/> > <attribute name="url" value=“..."/> > <attribute name="size" type="Long" value=“..."/> > <attribute name="mime" value="application/vnd.osgi.bundle"/> > </capability> > <capability namespace="osgi.wiring.bundle"> > <attribute name="osgi.wiring.bundle" value=“my.dependency"/> > <attribute name="bundle-version" type="Version" value=“1.0.0"/> > </capability> > > ... > *<capability namespace=“karaf.feature">* > *<attribute name=“feature.id > <http://feature.id>" value=“name.of.feature/1.0.0"/>* > *<attribute name=“start-level" value=“80"/>* > *<attribute name=“config" value=“com.foo.bar”>* > * <property name=“myProperty” value=“myValue”/>* > *</attribute>* > *</capability>* > > <requirement namespace="osgi.ee"> > <directive name="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 Schneiderhttp://www.liquid-reality.de > > Open Source Architecthttp://www.talend.com > >
