2015-11-26 11:04 GMT+01:00 Christian Schneider <[email protected]>:
> Hi Guillaume, > > as far as I know a bnd application is defined using a bndrun file and one > or more repositories. > So basically you define requirements and a bundle repository to resolve > against. Bndtools then creates the list of bundles interactively in the > eclipse bndtools UI. At build time you then already have the final list of > bundles. > I think this could be enhanced to also allow the resolve step to take > place at build time but as long as bndtools is doing the resolving we > probably would not notice the difference anyway on the karaf side. > > For the features to work in bndtools as well as in karaf we would need to > define a common format to define a requirement that represents a feature as > well as to represent the content of a feature. Ideally I think this should > then be standardized at some point > so it can be used in a wider range of environments. Ultimately it would be > great to even find a common way together with the eclipse pde community. > The requirement for a feature is already formalized in karaf: osgi.identity;osgi.identity=feature-name;type=karaf.feature;version="version-range" > Christian > > > Am 26.11.2015 um 10:16 schrieb Guillaume Nodet: > > 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> >> 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> >> 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 >> >> > >
